itu-t rec. g.875 (06/2020) optical transport network

I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n

ITU-T G.875 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU

(06/2020)

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

Digital networks – Optical transport networks

Optical transport network: Protocol-neutral management information model for the network element view

Recommendation ITU-T G.875

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

General aspects G.800–G.809

Design objectives for digital networks G.810–G.819

Synchronization, quality and availability targets G.820–G.829

Network capabilities and functions G.830–G.839

SDH network characteristics G.840–G.849

Management of transport network G.850–G.859

SDH radio and satellite systems integration G.860–G.869

Optical transport networks G.870–G.879

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

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.

Rec. ITU-T G.875 (06/2020) i


Optical transport network: Protocol-neutral management information model for

the network element view

Summary

Recommendation ITU-T G.875 (ex. ITU-T G.874.1) provides a protocol-neutral management

information model for managing network elements in the optical transport network (OTN). The

model contains the managed entities and their properties that are useful to describe the information

exchanged across interfaces defined in the ITU-T M.3010 telecommunications management network

(TMN) architecture. The protocol-neutral management information model shall be used as the base

for defining protocol-specific management information models, for example, common management

information service element (CMISE), common object request broker architecture (CORBA) and

simple network management protocol (SNMP) information models. Mapping from the protocol-

neutral entities into protocol-specific objects is a decision of the specific protocol modelling design

and should be described in the protocol-specific information model Recommendations.

The 2012 revision of this Recommendation updated the management information model to support

the management of the new transport functions that were introduced in the 2010 revision of

Recommendation ITU-T G.798 and also to support the management requirements enhancement

introduced in the 2010 revision of Recommendation ITU-T G.874.

Amendment 1 enhanced the model to cover delay measurement (DM), automatic protection

switching (APS) configuration, tributary slot configuration, and optical data unit (ODU) type and

rate configuration, and to remove the counting of incoming alignment errors (IAEs) and backward

incoming alignment errors (BIAEs).

Amendment 2 added: (1) the use of an organizationally unique identifier (OUI) to the description of

the attributes selectedApplicationIdentifier and supportableApplicationIdentifierList; and (2) sub-

classes the OTN current data and history data object classes from the ITU-T Q.822 current data and

history data object classes.

The 2016 revision of this Recommendation has incorporated Amendment 1 and Amendment 2, and

in addition the following updates: (1) changes the unified modelling language (UML) modelling tool

from RSA to open source Papyrus tool; (2) updates the ITU-T G.874.1 information model to align

with the ITU-T G.7711 v2.0 core information model; (3) drops subclassing the termination point

(TP) classes from ITU-T M.3160; and (4) supports the additional management requirements in

Recommendation ITU-T G.874.

The 2018 revision of this Recommendation up-versions the UML model tool to Papyrus v3.2.0 and

the profile to v0.2.13, updates the object class mapping figures to align with ITU-T G.798, updates

the model for ODU, optical transport unit (OTU), FlexO, optical tributary signal group – overhead

(OTSiG-O), optical channel – overhead (OCh-O), optical multiplex section – overhead (OMS-O),

and optical transmission section – overhead (OTS-O), adds Annex A for the OTN specification

model, deprecates the OTU CTP, OChr and optical physical section (OPS) (OPSn, OPSMnk, OPS0)

layer object classes to align with Recommendation ITU-T G.798.

The 2020 revision of this Recommendation up-versions the UML model tool to Papyrus v4.1.0 and

the profile to v0.2.17; updates and cleans up the model for ODU, adding support for ODUCn, ODU

delay measurement, GCC1/2 management, ODU clients (aligning with Recommendation ITU-T

G.709 v6), OTU and FlexO; add the model for generic framing procedure (GFP) management;

deprecates duplicated attributes and associations; un-deprecates the OTU CTP object classes and

fixes some other errors.

ii Rec. ITU-T G.875 (06/2020)

History

Edition Recommendation Approval Study Group Unique ID*

1.0 ITU-T G.874.1 2002-01-06 15 11.1002/1000/5608

2.0 ITU-T G.874.1 2012-10-29 15 11.1002/1000/11785

2.1 ITU-T G.874.1 (2012) Amd. 1 2013-08-29 15 11.1002/1000/11988

2.2 ITU-T G.874.1 (2012) Amd. 2 2015-08-13 15 11.1002/1000/12558

3.0 ITU-T G.874.1 2016-11-13 15 11.1002/1000/13087

4.0 ITU-T G.875 2018-12-14 15 11.1002/1000/13819

5.0 ITU-T G.875 2020-06-06 15 11.1002/1000/14241

Keywords

Information model, optical transport network (OTN), protocol-neutral, transport resource, unified

modelling language (UML).

* To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web

browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/11

830-en.

http://handle.itu.int/11.1002/1000/5608







http://handle.itu.int/11.1002/1000/11830-en

http://handle.itu.int/11.1002/1000/11830-en

Rec. ITU-T G.875 (06/2020) iii

FOREWORD

The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of

telecommunications, information and communication technologies (ICTs). The ITU Telecommunication

Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,

operating and tariff questions and issuing Recommendations on them with a view to standardizing

telecommunications on a worldwide basis.

The World Telecommunication Standardization Assembly (WTSA), which meets every four years,

establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on

these topics.

The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.

In some areas of information technology which fall within ITU-T's purview, the necessary standards are

prepared on a collaborative basis with ISO and IEC.

NOTE

In this Recommendation, the expression "Administration" is used for conciseness to indicate both a

telecommunication administration and a recognized operating agency.

Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain

mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the

Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some

other obligatory language such as "must" and the negative equivalents are used to express requirements. The

use of such words does not suggest that compliance with the Recommendation is required of any party.

INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may

involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence,

validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others

outside of the Recommendation development process.

As of the date of approval of this Recommendation, ITU had not received notice of intellectual property,

protected by patents, which may be required to implement this Recommendation. However, implementers

are cautioned that this may not represent the latest information and are therefore strongly urged to consult the

TSB patent database at http://www.itu.int/ITU-T/ipr/.

© ITU 2020

All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the

prior written permission of ITU.

http://www.itu.int/ITU-T/ipr/

iv Rec. ITU-T G.875 (06/2020)

Table of Contents

Page

1 Scope ............................................................................................................................ 1

2 References..................................................................................................................... 2

3 Definitions .................................................................................................................... 3

3.1 Definitions from [ITU-T M.3100] .................................................................. 3

3.2 Definitions from [ITU-T G.709] .................................................................... 4



3.5 Definitions from [ITU-T G.7710] .................................................................. 4

4 Abbreviations and acronyms ........................................................................................ 5

5 Conventions .................................................................................................................. 6

5.1 Information modelling conventions ............................................................... 6

6 Overview of the model ................................................................................................. 6

7 UML model class diagrams .......................................................................................... 12

7.1 High-level overview ....................................................................................... 12

7.2 OxS-O fragment ............................................................................................. 15

7.3 OCh fragment ................................................................................................. 16

7.4 OTU fragment ................................................................................................ 17

7.5 ODU fragment ................................................................................................ 18

7.6 FlexO fragment ............................................................................................... 20

7.7 NIM fragment ................................................................................................. 20

7.8 GCC fragment ................................................................................................ 21

7.9 Protection fragment ........................................................................................ 22

7.10 Performance monitoring (PM) fragment ........................................................ 25

7.11 Fault management fragment ........................................................................... 28

8 UML model file ............................................................................................................ 28

Annex A – OTN specification model ...................................................................................... 30

A.1 LTP/LP Specification model .......................................................................... 30

Appendix I – Usage of the model for TCM and GCC ............................................................. 34

I.1 TCM locations ................................................................................................ 36

I.2 GCC access locations ..................................................................................... 41

I.3 GCC access and TCM locations together ....................................................... 45

Appendix II – Management termination points ....................................................................... 51

II.1 State management ........................................................................................... 51

II.2 Location of TPs inside a ONE ........................................................................ 51

II.3 Definitions of ONE termination points .......................................................... 51

Appendix III – Mapping of [ITU-T G.798] atomic functions to ITU-T G.874.1

model artefacts .............................................................................................................. 53

Rec. ITU-T G.875 (06/2020) v

Page

Appendix IV – UML model data dictionary ............................................................................ 54

Appendix V – Overview of object class mapping to OxS-O trail protection sub-layer

functions ....................................................................................................................... 55

Appendix VI – Overview of the ODU adaptation functions configuration ............................. 56

VI.1 Client ODU over server ODU adaptation functions ....................................... 58

VI.2 ODU to packet adaptations ............................................................................. 62

VI.3 ODU to CBR, ETC and ERS clients ............................................................. 65

Appendix VII – Overview of the OTU/ODU adaptation functions configuration .................. 68

VII.1 OTUk/ODUk_A (clause 13.3.1 of [ITU-T G.798]) ....................................... 69

VII.2 OTUCn/ODUCn_A (clause 13.3.1 of [ITU-T G.798]) .................................. 72

Bibliography............................................................................................................................. 74

Rec. ITU-T G.875 (06/2020) 1


Optical transport network: Protocol-neutral management information model for

the network element view

1 Scope

This Recommendation provides a management/control-protocol-neutral information model for

managing/controlling network elements in the optical transport network (OTN) [ITU-T G.872],

[ITU-T G.709] and [ITU-T G.798]. It identifies the managed entities required for the

management/control of OTN network elements. These entities are relevant to information

exchanged across standardized interfaces defined in the M.3010 TMN architecture [ITU-T

M.3010]. The management/control-protocol-neutral information model should be used as the base

for defining management-protocol-specific information models, for examples, XML (Web Service

or Netconf/Yang) information model, CORBA IDL model, and SNMP MIB.

The information model defined in this Recommendation is an augmentation to the generic code

model specified in [ITU-T G.7711] for managing OTN transport resources. The core information

model defined in [ITU-T G.7711] can be used as the base for the extension of OTN-specific

information models.

The specific mapping of the management/control-protocol-neutral entities into

management/control-protocol-specific managed object classes is the decision of the

management/control-protocol-specific solution design. For example, an object class defined in this

Recommendation may be mapped into multiple tables in a SNMP MIB. On the other hand, all the

monitoring entities may be mapped into a single class in a protocol-specific model. Protocol-

specific solution and their mapping from the protocol-neutral model is outside the scope of this

Recommendation.

This Recommendation applies to OTN network elements and those systems that manage/control

OTN network elements. The management/control system could be an NMS, EMS, SDN controller

or hybrid of them. Recommendation [ITU-T G.7701] defines the management-control-continuum

(MCC) concept whereby management and control functions are considered to be a continuum.

Those systems are thus referred to as a management-control system (MCS) in general in this

Recommendation. Functional capabilities of OTN equipment are defined in [ITU-T G.798], and

requirements of the management of OTN equipment are provided in [ITU-T G.7710] and

[ITU-T G.874]. The information model specified in this Recommendation applies to the

management/control interface, as shown in Figure 1-1, specifically for managing/controlling the

OTN functional capabilities of the NE.

2 Rec. ITU-T G.875 (06/2020)

Figure 1-1 – Scope of interface

There are several different perspectives from which information may be defined for management

purposes. The network element viewpoint is concerned with the information that is required to

manage a network element. This refers to information required to manage the network element

function and the physical aspects of the network element. This Recommendation addresses only the

network element view of OTN management.

The management/control-protocol-neutral information model specified in this Recommendation

consists of a set of transport-technology-specific managed object classes, i.e., OTN-specific

managed object classes. These OTN-specific managed object classes are inherited from the generic

managed object classes defined in other ITU-T Recommendation such as [ITU-T G.711] and

[ITU-T M.3160], including Managed Element, Termination Point and its subclasses, Subnetwork,

and Subnetwork Connection 1 . Because of object class inheritance, the OTN management

information model also inherits the generic object management capabilities, such as object

creation/deletion, notification of object creation/deletion, attribute value retrieval/modification,

notification of attribute/state value change, scoped and filtered retrieval of object instances, and

abortion of outstanding operations. The description of these generic object management capabilities

is provided in other ITU-T Recommendations, such as the ITU-T M.3700 series, and therefore is

outside the scope of this Recommendation.

The object entities defined in this Recommendation apply to fault management and configuration

management.

2 References

The following ITU-T Recommendations and other references contain provisions which, through

reference in this text, constitute provisions of this Recommendation. At the time of publication, the

editions indicated were valid. All Recommendations and other references are subject to revision;

users of this Recommendation are therefore encouraged to investigate the possibility of applying the

most recent edition of the Recommendations and other references listed below. A list of the

1 The linkage of the OTN-specific object classes to the generic object classes is specified in details in

Appendix III.

Rec. ITU-T G.875 (06/2020) 3

currently valid ITU-T Recommendations is regularly published. The reference to a document within

this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.

[ITU-T G.709] Recommendation ITU-T G.709/Y.1331 (2020), Interfaces for the optical

transport network.

[ITU-T G.709.1] Recommendation ITU-T G.709.1/Y.1331.1 (2018), Flexible OTN short-reach

interfaces.

[ITU-T G.798] Recommendation ITU-T G.798 (2017), Characteristics of optical transport

network hierarchy equipment functional blocks.

[ITU-T G.872] Recommendation ITU-T G.872 (2019), Architecture of optical transport

networks.

[ITU-T G.874] Recommendation ITU-T G.874 (2020), Management aspects of optical

transport network elements.

[ITU-T G.7044] Recommendation ITU-T G.7044/Y.1347 (2011), Hitless adjustment of

ODUflex (GFP).

[ITU-T G.7701] Recommendation ITU-T G.7701 (2016), Common control aspects.

[ITU-T G.7710] Recommendation ITU-T G.7710/Y.1701 (2020), Common equipment

management function requirements.

[ITU-T G.7711] Recommendation ITU-T G.7711/Y.1702 (2018), Generic protocol-neutral

management Information Model for Transport Resources.

[ITU-T G.7712] Recommendation ITU-T G.7712/Y.1703 (2019), Architecture and

specification of data communication network.

[ITU-T G.8051] Recommendation ITU-T G.8051/Y.1345 (2020), Management aspects of the

Ethernet transport (ET) capable network element.

[ITU-T G.8052] Recommendation ITU-T G.8052/Y.1346 (2018), Protocol-neutral management

information model for the Ethernet transport capable network element.

[ITU-T G.8152] Recommendation ITU-T G.8152/Y.1375 (2018), Protocol-neutral management

information model for the MPLS-TP network element.

[ITU-T M.3010] Recommendation ITU-T M.3010 (2000), Principles for a telecommunications

management network.

[ITU-T M.3100] Recommendation ITU-T M.3100 (2005), Generic network information model.

[ITU-T Q.822] Recommendation ITU-T Q.822 (1994), Stage 1, stage 2 and stage 3

description for the Q3 interface – Performance management.

[ITU-T X.680] Recommendation ITU-T X.680 (2015), Information technology – Abstract

Syntax Notation One (ASN.1): Specification of basic notation.

[ITU-T X.731] Recommendation ITU-T X.731 (1992), Information technology – Open

Systems Interconnection – Systems Management: State management function.

[ITU-T X.739] Recommendation ITU-T X.739 (1993), Information technology – Open

Systems Interconnection – Systems Management: Metric objects and attributes.

3 Definitions

3.1 Definitions from [ITU-T M.3100]

The following terms are defined in [ITU-T M.3100] and used in this Recommendation:

4 Rec. ITU-T G.875 (06/2020)

ASAP Alarm Severity Assignment Profile

CTP Connection Termination Point

TP Termination Point

TTP Trail Termination Point

3.2 Definitions from [ITU-T G.709]

The following terms are defined in [ITU-T G.709] and used in this Recommendation:

OCh Optical Channel

ODU Optical Data Unit

ODUk Optical Data Unit-k

ODUCn Optical Data Unit-Cn

ODUkP Optical Data Unit-k, Path monitoring level

ODUCnP Optical Data Unit-Cn, Path monitoring level

ODUkT Optical Data Unit-k, Tandem connection sublayer

ODUCnT Optical Data Unit-Cn, Tandem connection sublayer

OPS Optical Physical Section

OPU Optical Payload Unit

OTM Optical Transport Module

OTN Optical Transport Network

OTU Optical Transport Unit

OTUk completely standardized Optical Transport Unit-k

OTUCn completely standardized Optical Transport Unit-Cn



OMS Optical Multiplex Section

OTS Optical Transmission Section



A Adaptation function

GCC General Communication Channel

MP Management Point

TT Trail Termination function


The following term is defined in [ITU-T G.7710] and used in this Recommendation:

ARC Alarm Reporting Control

Rec. ITU-T G.875 (06/2020) 5

4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:

APS Automatic Protection Switching

ARC Alarm Reporting Control

ASAP Alarm Severity Assignment Profile

BIAE Backward Incoming Alignment Error

CMISE Common Management Information Service Element

CORBA Common Object Request Broker Architecture

CTP Connection Termination Point

DCN Data Communication Network

DM Delay Measurement

GCC General Communication Channel

GFP Generic Framing Procedure

IAE Incoming Alignment Error

IDL Interface Definition Language

LP Layer Protocol

LTP Logical Termination Point

MP Management Point

NE Network Element

NIM Non-Intrusive Monitoring

OCh-O Optical Channel – Overhead

ODU Optical Data Unit

ODUk/Cn Optical Data Unit-k/Cn

ODUk/CnP Optical channel Data Unit-k/Cn, Path monitoring level

ODUk/CnT Optical channel Data Unit-k/Cn, Tandem connection sublayer

OMS Optical Multiplex Section

OMS-O Optical Multiplex Section – Overhead

ONE Optical Network Element

OPS Optical Physical Section

OPU Optical Payload Unit

OS Operating System

OTM Optical Transport Module

OTN Optical Transport Network

OTS Optical Transmission Section

OTSi Optical Tributary Signal

OTSiA Optical Tributary Signal Assembly

OTSiG Optical Tributary Signal Group

6 Rec. ITU-T G.875 (06/2020)

OTSiG-O Optical Tributary Signal Group – Overhead

OTS-O Optical Transmission Section – Overhead

OTU Optical Transport Unit

OTUk/Cn Completely standardized Optical Transport Unit-k/Cn

OUI Organizationally Unique Identifier

SNMP Simple Network Management Protocol

TCM Tandem Connection Monitoring

TMN Telecommunication Management Network

TP Termination Point

TT Trail Termination function

TTP Trail Termination Point

UML Unified Modelling Language

WDM Wavelength Division Multiplexing

5 Conventions

5.1 Information modelling conventions

5.1.1 UML modelling conventions

See [ITU-T G.7711] clause 5.1.

5.1.2 Model artefact lifecycle stereotypes conventions


5.1.3 Forwarding entity terminology conventions


5.1.4 Conditional package conventions


5.1.5 Pictorial diagram conventions


6 Overview of the model

This Recommendation models the optical transport network (OTN) transport functions that are

relevant to OTN network elements management. These functions are defined in the equipment

specification [ITU-T G.798] for the termination, adaptation, and connection functions of the OTN

layers, including optical transmission section –overhead (OTS-O), optical multiplex section –

overhead (OMS-O), optical tributary signal group –overhead (OTSiG-O), optical channel –

overhead (OCh-O), optical transmission unit (OTU), optical data unit (ODU), tandem connection

sublayer of optical data unit of level k (ODUkT), and the FlexO and OTSi adaptation functions. In

particular, the input and output information exchanged at the management point (MP) are modelled.

The termination, adaptation, and connections functions and input/output information cover the areas

of configuration, fault management, and performance management as described in [ITU-T G.7710]

and [ITU-T G.874]. Details of the management functions that need to be modelled are provided in

[ITU-T G.7710] and [ITU-T G.874].

Rec. ITU-T G.875 (06/2020) 7

In this Recommendation, managed resources and management support resources are modelled as

objects in the information model. The management view of a resource is a managed object. This

Recommendation specifies the properties of the resources visible for management. Objects with

similar properties are grouped into object classes. An object instance is an instantiation of an object

class. The properties of an object include the behaviour, attributes and operations that can be

applied to the object. An object instance is characterized by its object class and may possess

multiple attribute types and associated values. In the protocol-neutral model, object classes are

represented as unified modelling language (UML) classes.

Object classes, attribute types and operations are defined for the purpose of communicating network

management messages between systems. They need not be related to the structure of data stored

within those systems.

An object class may be a subclass of another class. A subclass inherits properties of its superclass,

in addition to possessing its own specific attributes and properties. In this Recommendation, the

OTN-specific transport object classes are defined. These object classes are not inherited from any

generic transport superclasses. In the future, when defining protocol-specific OTN object classes,

they could be mapped from the protocol-neutral OTN object classes and also inherited from the

protocol-specific generic transport object classes for additional properties.

In addition to the OTN resource, the model also includes object classes for management support

functions such as alarm reporting control and alarm severity assignment.

Figures 6-1 to 6-5 below show the mapping between the OTN managed object classes and the OTN

atomic functions defined in Figures 1-1 to 1-5 of [ITU-T G.798].

Figure 6-1 – Overview of object class mapping to OTN atomic functions that support single-

OTU (SOTU) and muti-OTU (MOTU) interface

(Based on Figure 1-1 of [ITU-T G.798])

8 Rec. ITU-T G.875 (06/2020)

Figure 6-2 – Overview of object class mapping to OTN atomic functions that support muti-

OTU (MOTUm) with management interface

(Based on Figure 1-2 of [ITU T G.798])

Rec. ITU-T G.875 (06/2020) 9

Figure 6-3 – Overview of object class mapping to OTN atomic functions specific for the non-

associated overhead information


10 Rec. ITU-T G.875 (06/2020)

Figure 6-4 – Overview of object class mapping to OTN atomic functions for FlexO


Rec. ITU-T G.875 (06/2020) 11

12 Rec. ITU-T G.875 (06/2020)

Figure 6-5 – Overview of object class mapping to OTN common atomic functions


7 UML model class diagrams

This clause contains the UML model class diagrams of the OTN NE management-protocol-neutral

information model.

7.1 High-level overview

The UML diagrams shown in Figures 7-1a to 7-1c provide a high-level overview of most of the

OTN specific managed object classes without showing the details, such as the attributes and

operations of the object classes. Figure 7-1a shows a high level overview of the OTN model. Figure

7-1b shows the OTN main entities and Figure 7-1c shows OTN inheritance.

More detailed class diagrams for the individual fragments of the model are shown in Figures 7-2 to

7-11, in which the attributes and operations are also shown.

Rec. ITU-T G.875 (06/2020) 13

NOTE – This figure is also available from the ITU website here.

Figure 7-1a – OTN model high level overview

https://www.itu.int/ITU-T/formal-language/itu-t/g/g875/2020/G.875_v5.00_FIG.zip

14 Rec. ITU-T G.875 (06/2020)


Figure 7-1b – OTN main entities


Rec. ITU-T G.875 (06/2020) 15


Figure 7-1c – OTN inheritance

7.2 OxS-O fragment


Figure 7-2 – OTS-O and OMS-O entities



16 Rec. ITU-T G.875 (06/2020)

7.3 OCh fragment


Figure 7-3 – OCh entities


Rec. ITU-T G.875 (06/2020) 17

7.4 OTU fragment


Figure 7-4 – OTU entities


18 Rec. ITU-T G.875 (06/2020)

7.5 ODU fragment


Figure 7-5a – ODU entities


Rec. ITU-T G.875 (06/2020) 19

NOTE – This figure is also available from the ITU website here

Figure 7-5b – ODUCn and ODUk Pacs


Figure 7-5c – ODU TCM entities



20 Rec. ITU-T G.875 (06/2020)

7.6 FlexO fragment


Figure 7-6 – FlexO entities

7.7 NIM fragment


Figure 7-7 – Non-intrusive monitoring (NIM) entities



Rec. ITU-T G.875 (06/2020) 21

7.8 GCC fragment

The general communication channel (GCC) fragment models the COMMs functions, defined in

clause 14.4 of [ITU-T G.798], to provide access to the ODU GCC overhead.

Only the GCC12 TP Bidirectional object class is a concrete object class since ECC (GCC) channels

are supporting bidirectional data communication network (DCN) links in [ITU-T G.7712].

The GCC12 TP Bidir object class models the different accesses to the ODU GCC1/2:

• The access to an ODU GCC1/2 at an ODU adaptation point (ODU_AP), as shown in Figure

14-103a of [ITU-T G.798], is modelled using a GCC12 TP Bidir instance contained by the

ODU TTP Bidir instance, which represents that ODU_AP.

• The access to an ODU GCC1/2 at an ODU (termination) connection point (ODU_CP/TCP),

as shown in Figure 14-103b of [ITU-T G.798], is modelled using a GCC12 TP Bidir

instance contained by the ODU CTP or TTP Bidir instance which represents that

ODU_CP/TCP.

The positionSeq attribute of the containing ODU TTP or CTP instances represents the relative

position of the different GCC12 TP instances providing access to multiple GCC1/2 at that ODU

(termination) connection point (ODU_CP/TCP), also respect to any TCM endpoints at the same

ODU (termination) connection point.

A GCC12 TP instance providing access to GCC1/2 at an ODU_AP will never appear in the

positionSeq attribute of the containing ODU TTP instance while a GCC12 TP instance providing

access to GCC1/2 at an ODU_TCP will always appear in the positionSeq attribute of the containing

ODU TTP instance even when it is the only auxiliary function contained by that ODU TTP

instance.

Some examples of GCC12 TP configurations are provided in clauses I.2 and I.3.


Figure 7-8 – GCC entities


22 Rec. ITU-T G.875 (06/2020)

7.9 Protection fragment


Figure 7-9a –OCh protection


Rec. ITU-T G.875 (06/2020) 23


Figure 7-9b – ODU protection


24 Rec. ITU-T G.875 (06/2020)


Figure 7-9c – OTS-O and OMS-O trail protection


Rec. ITU-T G.875 (06/2020) 25

7.10 Performance monitoring (PM) fragment


Figure 7-10a – Performance monitoring entities


26 Rec. ITU-T G.875 (06/2020)

7.10.1 Delay measurement

The following figures provide an overview of the OTN delay measurement function showing

involved atomic functions, management information and managed object classes.

Figure 7-10b – ODU path delay measurement

Rec. ITU-T G.875 (06/2020) 27

Figure 7-10c – ODUk tandem connection delay measurement

28 Rec. ITU-T G.875 (06/2020)


Figure 7-10d – Delay measurement entities

7.11 Fault management fragment

Figure 7-11 – Fault management entities

8 UML model file

The ITU-T G.875 (ex. ITU-T G.874.1) UML model is contained in a repository website. The

following links provide the pointers to the ITU-T G.875 UML model files and the supporting

materials.


Rec. ITU-T G.875 (06/2020) 29

– G.875_v5.00_PAP.zip

This zip contains the ITU-T G.875 model files (i.e., the.project, .di, .notation and .uml files)

and the profiles.

The G.875 5.00 model uses the following modelling tool and profiles

o Eclipse 4.9 (i.e. version 2018.09)

o Papyrus 4.1.0,

o OpenModel_Profile 0.2.17,

o OpenInterfaceModel_Profile 0.0.10,

o ProfileLifecycle_Profile 0.0.4, and

o Gendoc v0.7.1

– G.875_v5.00_DD.zip

This zip file is the data dictionary.

To use the ITU-T G.875 model, the [ITU-T G.7711], the [ITU-T G.8052] and [ITU-T G.8152]

models also need to be installed:

– G.7711_v2.02_PAP.zip

This contains the [ITU-T G.7711model files. In order to use the ITU-T G.875 model, the

ITU-T G.7711 v3.00 base model also needs to be installed.

– G.8052_v3.00_PAP.zip

This contains the [ITU-T G.8052] model files. In order to use the ITU-T G.875 model, the

ITU-T G.8052 v3.00 Ethernet model also need to be installed.

– G.8152_v2.00_PAP.zip

This contains the [ITU-T G.8152] model files. In order to use the ITU-T G.875 model, the

ITU-T G.8052 v2.00 MPLS-TP model also need to be installed.

NOTE – The ITU-T G.875 UML information models and the open model profile are specified using the

Papyrus open-source modelling tool. In order to view and further extend or modify the information model,

the open source Eclipse software and the Papyrus tool need to be installed, which are available at [b-Eclipse-

Papyrus]. The installation guide for Eclipse and Papyrus can be found in [b-ONF TR-515].

https://www.itu.int/ITU-T/formal-language/itu-t/g/g875/2020/G.875_v5.00_PAP.zip

https://www.itu.int/ITU-T/formal-language/itu-t/g/g875/2020/G.875_v5.00_DD.zip

http://www.itu.int/itu-t/formal-language/itu-t/g/g7711/2018/G.7711_v2.02_PAP.zip



30 Rec. ITU-T G.875 (06/2020)

Annex A

OTN specification model

(This annex forms an integral part of this Recommendation.)

This annex describes how the Recommendation ITU-T G.7711 Specification model is used to

augment the Core model with the OTN specific properties.

A.1 LTP/LP Specification model

A.1.1 Overview of the Core LTP/LP Specification model

[ITU-T G.7711] defines in Annex G.3.2 a generic logical termination point (LTP) and layer

protocol (LP) specification model that provides a representation of layer protocol (LP) specific

parameters for the LTP. Reproduced below is Figure G.3-18 of [ITU-T G.7711], which shows the

LTP/LP spec elements.

Figure A.1-1 – Relating LTP/LP spec elements

(From Figure G.3-18 of [ITU-T G.7711] – Relating LTP/LP spec elements)

As shown in the figure, the LpSpec class is the touch point to anchor the spec elements for

specifying the various capabilities of a specific type of LP. Among the spec elements, the following

two are particularly relevant to the layer specific parameters of the termination points defined in the

technology specific recommendations.

ConnectionPointAndAdapterSpec is defined in Annex G.3.2.3.3 of [ITU-T G.7711] as follows:

Rec. ITU-T G.875 (06/2020) 31

The specification of the server facing connection point and the adapter that deals with the

transformation of a single signal of the layer protocol to/from the server. Equivalent to an

ITU-T CTP [ITU-T G.8052].

TerminationSpec is defined in Annex G.3.2.3.11 of [ITU-T G.7711] as follows:

The specification of the layer protocol termination (including framing, modulation etc.).

For example, the specification of the function that takes a MAC frame and extracts the

content (removing the MAC address in the process).

Although it was not explicated stated, the TerminationSpec is obviously equivalent to an

ITU-T TTP.

A.1.2 Consideration of OTN specification cases for LTP/LP

Considering

• The benefit of easy traceability between the attributes of the technology-specific OTN

TTP/CTP of the information models with the corresponding management information

(i.e., the MI signals) of the ITU-T G.798 OTN technology specific equipment function

specifications,

– This Recommendation is continuing to keep the current TTP/CTP in the technology-

specific information models

• The equivalency of the TTP/CTP to the spec elements, namely TerminationSpec and

ConnectionPointAndAdapterSpec respectively,

– This Recommendation enhances the technology-specific information models to

augment, for each layer, the core model generic TerminationSpec and

ConnectionPointAndAdapterSpec with the technology-specific TTP and CTP.

A.1.3 OTN specification classes for LTP/LP

For each OTN layer, the core model generic TerminationSpec and

ConnectionPointAndAdapterSpec is augmented with the TTP and CTP object classes as shown in

the UML diagrams of Figures A.1-2 and A.1-3.

32 Rec. ITU-T G.875 (06/2020)

A.1.3.1 OTU specification classes for LTP/LP

Figure A.1-2 – OTU spec case

Rec. ITU-T G.875 (06/2020) 33

A.1.3.2 ODU specification classes for LTP/LP

Figure A.1-3 ODU spec case

34 Rec. ITU-T G.875 (06/2020)

Appendix I

Usage of the model for TCM and GCC

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

This appendix provides some examples to illustrate possible positions of TCM and GCC access

functions within ODUk TPs and how they will be represented in the information model. This

representation is defined via the use of containment relationships and the attributes PositionSeq,

Codirectional and Directionality.

The ODUk layer network configuration shown in Figure I.1 will be used as a basis:

35 Rec. ITU-T G.875 (06/2020)

Figure I.1 – ODUk layer network configuration

36 Rec. ITU-T G.875 (06/2020)

I.1 TCM locations

I.1.1 TC_Trail between ODUk_CTP source and ODUk_CTP sink (points C and D)

Figure I.2 – TC_Trail between ODUk_CTP source and ODUk_CTP sink (points C and D)

Table I.1 – Containment relationships and PositionSeq, Codirectional and Directionality attributes

Object Contains PositionSeq Codirectional Directionality

ODUk_CTP at Point C ODUkT_TTP #45 ODUkT_TTP #45 – Source

ODUkT_TTP #45 – – True Source

ODUk_CTP at Point D ODUkT_TTP #6 ODUkT_TTP #6 – Sink

ODUkT_TTP #6 – – True Sink

37 Rec. ITU-T G.875 (06/2020)

I.1.2 TC_Trail between ODUk_CTP sink and ODUk_CTP source (points E and F)

Figure I.3 – TC_Trail between ODUk_CTP sink and ODUk_CTP source (points E and F)



ODUk_CTP at Point E ODUkT_TTP #23 ODUkT_TTP #23 – Sink

ODUkT_TTP #23 – – False Source

ODUk_CTP at Point F ODUkT_TTP #87 ODUkT_TTP #87 – Source

ODUkT_TTP #87 – – False Sink

38 Rec. ITU-T G.875 (06/2020)

I.1.3 TC_Trail between ODUk_TTP source and ODUk_CTP source (points G and H)

Figure I.4 – TC_Trail between ODUk_TTP source and ODUk_CTP source (points G and H)

Table I.3 – Containment relationships and PositionSeq, Codirectional and Directionality

attributes


ODUk_TTP at Point G ODUkT_TTP #3 ODUkT_TTP #3 – Source

ODUkT_TTP #3 – – meaningless Source

ODUk_CTP at Point H ODUkT_TTP #65 ODUkT_TTP #65 – Source


39 Rec. ITU-T G.875 (06/2020)

I.1.4 Two TC_Trail terminations within one ODUk_CTP

Figure I.5 – Two TC_Trail terminations within one ODUk_CTP

40 Rec. ITU-T G.875 (06/2020)


attributes


ODUk_CTP at Point C ODUkT_TTP #19 ODUkT_TTP #19 – Source

ODUkT_TTP #19 – – True Source

ODUk_CTP at Point E ODUkT_TTP #18 ODUkT_TTP #18 – Sink

ODUkT_TTP #18 – – False Source

ODUk_CTP at Point F ODUkT_TTP #1

ODUkT_TTP #3

ODUkT_TTP #3

ODUkT_TTP #1

– Source



41 Rec. ITU-T G.875 (06/2020)

I.2 GCC access locations

I.2.1 COMMS channel between two ODUk_TTPs

Figure I.6 – COMMS channel between two ODUk_TTPs



ODUk_TTP at Point A GCC12_TP #100 empty – Bidirectional

GCC12_TP #100 – – – Bidirectional

ODUk_TTP at Point B GCC12_TP #2 empty – Bidirectional


42 Rec. ITU-T G.875 (06/2020)

I.2.2 COMMS channel between ODUk_CTP and ODUk_TTP

Figure I.7 – COMMS channel between ODUk_CTP and ODUk_TTP



ODUk_CTP at Point C GCC12_TP #22 Optional:

GCC12_TP #22

– Bidirectional

GCC12_TP #22 – – True Bidirectional

ODUk_TTP at Point B GCC12_TP #13 GCC12_TP #13 – Bidirectional


43 Rec. ITU-T G.875 (06/2020)

I.2.3 Several COMMS channels

Figure I.8 – Several COMMS channels

44 Rec. ITU-T G.875 (06/2020)


attributes

Object Contains Position

Seq

Codirec-

tional

Direc-

tionality GCCAccess

ODUk_CTP at Point E GCC12_TP #6

GCC12_TP #9

Optional:

GCC12_TP #9

GCC12_TP #6

– Bidirectional –

GCC12_TP #6 – – False Bidirectional GCC1

GCC12_TP #9 – – True Bidirectional GCC1

ODUk_CTP at Point F GCC12_TP #4

GCC12_TP #45

GCC12_TP #2

GCC12_TP #8

GCC12_TP #8

GCC12_TP #2

GCC12_TP #45

GCC12_TP #4






ODUk_CTP at Point B GCC12_TP #34

GCC12_TP #5

Optional:

GCC12_TP #5

GCC12_TP #34




45 Rec. ITU-T G.875 (06/2020)

I.3 GCC access and TCM locations together

I.3.1 TC_Trail and COMMS channel two ODUk_CTPs

Figure I.9 – TC_Trail and COMMS channel two ODUk_CTPs

46 Rec. ITU-T G.875 (06/2020)


attributes


ODUk_CTP at Point C GCC12_TP #3

ODUkT_TTP #57

ODUkT_TTP #57

GCC12_TP #3

– Bidirectional


ODUkT_TTP #57 – – True Bidirectional

ODUk_CTP at Point D GCC12_TP #23

ODUkT_TTP #44

ODUkT_TTP #44

GCC12_TP #23

– Bidirectional


ODUkT_TTP #44 – – True Bidirectional

47 Rec. ITU-T G.875 (06/2020)

I.3.2 Terminating TC_Trail and inserting GCC within one ODUk_CTP

Figure I.10 – Terminating TC_Trail and inserting GCC within one ODUk_CTP

48 Rec. ITU-T G.875 (06/2020)


attributes


ODUk_CTP at Point E ODUkT_TTP #87 Optional:

ODUkT_TTP #87

– Bidirectional

ODUkT_TTP #87 False Bidirectional

ODUk_CTP at Point F ODUkT_TTP #65

GCC12_TP #43

Optional:

GCC12_TP #43

ODUkT_TTP #65

– Bidirectional

ODUkT_TTP #65 – – False Bidirectional


ODUk_CTP

at Point B

GCC12_TP #8 Optional:

GCC12_TP #8

– Bidirectional


I.3.3 Bidirectional example with TCM and GCC access

Figure I.11 – Bidirectional example with TCM and GCC access

To ensure readability, only the ODUk_CTP at point F is shown in Table I.10. The other two

ODUk_CTPs at E and B are as shown in clause I.2.3.

Rec. ITU-T G.875 (06/2020) 49


attributes

Object Contains PositionSeq Codirec-

tional

Direc-

tionality

GCCAccess/

field

ODUk_CTP

at Point F

ODUkT_TTP #1

GCC12_TP #4

ODUkT_nim #98

GCC12_TP #45

GCC12_TP #2

ODUkT_TTP #49

GCC12_TP #8

GCC12_TP #8

ODUkT_TTP #49

GCC12_TP #2

GCC12_TP #45

ODUkT_nim #98

GCC12_TP #4

ODUkT_TTP #1


ODUkT_TTP #1 – – False Bidirectional 5


ODUkT_nim #98 – – Bidirectional 3



ODUkT_TTP #49 – – True Bidirectional 5


I.3.4 GCC12TP orientation

Figure I.12 – Bidirectional Gcc12Tp contained by bidirectional TTP

50 Rec. ITU-T G.875 (06/2020)

Figure I.13 – Bidirectional Gcc12Tp contained by bidirectional TTP and CTP

Figure I.14 – Bidirectional Gcc12Tp contained by bidirectional TTP and CTP

Rec. ITU-T G.875 (06/2020) 51

Appendix II

Management termination points


II.1 State management

The optical network element (ONE) shall indicate to the operating system (OS) when a termination

point is no longer able to supervise the signal (e.g., implementing equipment has a fault or loss of

power).

II.2 Location of TPs inside a ONE

Figure II.1 shows possible locations of termination points (TPs) inside a network element (the

network elements are just examples; it is not necessary to define specific NE types):

Figure II.1 – Example of TPs in an optical amplifier

II.3 Definitions of ONE termination points

An otsTTPSource originates a wavelength division multiplexing (WDM) transmission trail

between two adjacent optical network elements. This object class represents the point where the

optical line signal outgoes from the network element (NE). There is always one instance of an

otsTTPSource per line output port.

An otsTTPSink terminates a WDM transmission trail between two adjacent optical networks. This

object class represents the point where the optical line signal incomes into the NE. There is always

one instance of an otsTTPSink per line input port.

An omsCTPSource originates an optical multiplex section link connection between two adjacent

optical network elements (ONEs). There is one instance (for the time being; in future there may be

more) of an omsCTPSource per line output port.

52 Rec. ITU-T G.875 (06/2020)

An omsCTPSink terminates an optical multiplex section link connection between two adjacent

optical network elements. There is one instance (for the time being; in future there may be more) of

an omsCTPSink per line input port.

An omsTTPSource originates an optical multiplex section trail between two (not necessarily

adjacent) optical network elements. There is one instance (for the time being; in future there may be

more) of an omsTTPSource per line output port.

An omsTTPSink terminates an optical multiplex section trail between two (not necessarily

adjacent) optical network elements. There is one instance (for the time being; in future there may be

more) of an omsTTPSink per line input port.

An ochCTPSource originates an optical channel link connection between two (not necessarily

adjacent) optical network elements. There is one instance of an ochCTPSource per wavelength

channel in a line output port.

An ochCTPSink terminates an optical channel link connection between two (not necessarily

adjacent) optical network elements. There is one instance of an ochCTPSource per wavelength

channel in a line input port.

An ochTTPSource originates an optical channel trail between two (not necessarily adjacent)

optical network elements. There is one instance of an ochTTPSource per OCh adapter.

An ochTTPSink terminates an optical channel trail between two (not necessarily adjacent) optical

network elements. There is one instance of an ochTTPSink per OCh adapter.

Rec. ITU-T G.875 (06/2020) 53

Appendix III

Mapping of [ITU-T G.798] atomic functions to ITU-T G.874.1 model artefacts


This appendix provides further detail mapping between the [ITU-T G.798] atomic functions and the

ITU-T G.874.1 UML model artifacts. Note that in some cases a 1:1 mapping is not possible.

Table III.1 – Mapping between [ITU-T G.798] OTN atomic functions and UML model

artifacts

For further study.

54 Rec. ITU-T G.875 (06/2020)

Appendix IV

UML model data dictionary


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. This detailed information is generated

automatically by a Gendoc tool from the UML model.

The ITU-T G.875 data dictionary is provided in the G.875_v5.00_DD.zip file at the repository

mentioned in clause 8.

Rec. ITU-T G.875 (06/2020) 55

Appendix V

Overview of object class mapping to OxS-O trail protection sub-layer functions


Trail protection is modelled as an expansion of the access point for a trail to include a protection

sublayer. The expansion is identical for both the OTS-O and OMS-O layers, so it is described here

with "OxS-O" nomenclature.

Figure V.1 shows the overview of object class mapping to OxS-O trail protection sub-layer

functions.

Figure V.1 – Overview of object class mapping to OxS-O trail protection sub-layer functions

(Based on Figure VIII.1 of [ITU T G.798])

56 Rec. ITU-T G.875 (06/2020)

Appendix VI

Overview of the ODU adaptation functions configuration


Within an OTN network element (NE), the EMF creates a specific ODUkP/<client>_A atomic

function, defined in [ITU-T G.798], when a server ODU TTP object class instance is created, based

on the configured oduType, clientType and mappingType attributes, as summarized in Table VI.1.

Table VI.1 – Summary of the ODUkP/<client>_A atomic functions

oduType clientType mappingType ITU-T G.798 adaptation function

Clause of

this

appendix

ODU1 ODU AMP (Note 1) ODU1P/ODU0_A 14.3.9 VI.1.1

ODU2 ODU [2] AMP (Note 1) ODU2P/ODU1_A 14.3.9 VI.1.1

ODU3 ODU [2] AMP (Note 1) ODU3P/ODU1_A [3]

ODU3P/ODU2_A [3]

ODU3P/ODU12_A [3]

14.3.9 VI.1.1

VI.1.1

VI.1.2

ODUk

(k=2, 3, 4)

ODU [4] AMP-GMP (Note

1)

ODUkP/ODUj-21_A

(k=2, 3, 4)

14.3.10 VI.1.3

ODUCn ODU AMP-GMP ODUCnP/ODUk_A 14.3.16 VI.1.4

ODUk [5] MPLS GFP-F ODUkP/MT_A 14.3.19 VI.2.1

ODUk [5] ETHERNET GFP-F ODUkP/ETH_A 14.3.11 VI.2.2

ODU0 ETH_1GE TTT+GMP (Note

6)

ODU0P/CBRx-g

(x=ETC1000X)

14.3.8 VI.3

ODU2 ETH_10GE_WAN

OC_192

STM_64

AMP (Note 6) ODU2P/CBRx-a_A

(x=10G)

14.3.1 VI.3

ODU2 ETH_10GE_WAN

OC_192

STM_64

BMP (Note 6) ODU2P/CBRx-b_A

(x=10G)

14.3.1 VI.3

ODU2e ETH_10GE_LAN 16FS+BMP (Note

6)

ODU2eP/CBRx-b_A

(x=10G3)

14.3.1 VI.3

ODU2 ETH_10GE_LAN GFP-F ODU2P/ERS10G_A 14.3.3 VI.3

ODUflex ETH_25GE BMP ODUflexP/ETCy_A

(y=25GR)

14.3.20 VI.3

ODU3 ETH_40GE TTP+GMP ODU3P/CBRx-g_A

(x=ETC40GR)

14.3.8 VI.3

ODU4 ETH_100GE GMP ODU4P/ CBRx-g_A

(x=ETC100GR)

14.3.8 VI.3


(y=200GR)

14.3.20 VI.3


(y=400GR)

14.3.20 VI.3

ODU0 FC_100 GMP ODU0P/CBRx-g_A

(x=FC-100)

14.3.8 VI.3

ODU1 FC_200 GMP ODU1P/CBRx-g_A 14.3.8 VI.3

Rec. ITU-T G.875 (06/2020) 57



Clause of

this

appendix

(x=FC-200)

ODUflex FC_400 BMP ODUflex/CBRx-b_A

(x=FC-400) [7]

14.3.1 VI.3


(x=FC-800) [7]

14.3.1 VI.3

ODU2e FC_1200 TTT+16FS+BMP ODU2eP/FC-1200_A 14.3.15 VI.3


(x=FC-1600) [7]

14.3.1 VI.3


(x=FC-3200) [7]

14.3.1 VI.3

ODU0 STM_1

OC_3

GMP ODU0P/CBRx-g_A

(x=155M)

14.3.8 VI.3

ODU0 STM_4

OC_12

GMP ODU0P/CBRx-g_A

(x=622M)

14.3.8 VI.3

ODU1 STM_16

OC_48

AMP ODU1P/CBRx-a_A

(x=2G5)

14.3.1 VI.3

ODU1 STM_16

OC_48

BMP ODU1P/CBRx-b_A

(x=2G5)

14.3.1 VI.3

ODU3 STM_256

OC_768

AMP ODU3P/CBRx-a_A

(x=40G)

14.3.1 VI.3

ODU3 STM_256

OC_768

BMP ODU3P/CBRx-b_A

(x=40G)

14.3.1 VI.3

ODU1 CM_GPON AMP ODU1P/CBRx-a_A

(x=2G5) [8]

14.3.1 VI.3

ODU2 CM_XGPON AMP ODU2P/CBRx-a_A

(x=10G) [8]

14.3.1 VI.3

ODUflex IB_SDR BMP ODUflex/CBRx-b_A

(x=IB SDR) [7]

14.3.1 VI.3

ODUflex IB_DDR BMP ODUflex/CBRx-b_A

(x=IB DDR) [7]

14.3.1 VI.3

ODUflex IB_QDR BMP ODUflex/CBRx-b_A

(x=IB QDR) [7]

14.3.1 VI.3

ODU0 SBCON GMP ODU0P/CBRx-g_A

(x=SBCON/ESCON)

14.3.8 VI.3

ODU0 DVB_ASI GMP ODU0P/CBRx-g_A

(x=DVB-ASI)

14.3.8 VI.3

ODUflex 3G_SDI [9]

3G_SDI_1dot001 (Note

10)

BMP ODUflex/CBRx-b_A

(x=3G SDI) [7]

14.3.1 VI.3

ODU1 SDH_RSn AMP ODU1P/RS16_A 14.3.6 (Note 11)

ODU1 SDH_RSn BMP ODU1P/RS16_A 14.3.6 (Note 11)





58 Rec. ITU-T G.875 (06/2020)



Clause of

this

appendix

Note 1 – See Table X.1 of [ITU-T G.709].

Note 2 – The opuTributarySlotSize should also be set to "2G5".

Note 3 – The EMF decides which atomic to create depending on the hardware capabilities: if only type of client ODU CTPs (only

ODU1 or only ODU2) are supported the ODU3P/ODU1_A or, respectively, the ODU3P/ODU2_A atomic function is created;

otherwise, the ODU3P/ODU12_A atomic function is created.

Note 4 – The opuTributarySlotSize should also be set to "1G25".

Note 5 – Any oduType different than ODUCn (e.g., ODU_FLEX).

Note 6 – See Table IX.1 of [ITU-T G.709].

Note 7 – This client signal is one of the client signals identified as "Any other rate above 2G5" in Table 14-4 of [ITU-T G.798]

and listed in Table 17-14 of [ITU-T G.709].

Note 8 – The CM-GPON and CM-XGPON signals have a 32ppm clock tolerance as described in Table 14-5 of [ITU-T G.709].

Note 9 – 3G_SDI rate is 2.970 Gbit/s and payload type is 0x19, as defined in Table 15-9 of

[ITU-T G.709].

Note 10 – 3G_SDI_1dot00 rate is (2.970/1.001) Gbit/s and payload type is 0x18, as defined in Table 15-9 of [ITU-T G.709].

Note 11 – The behaviour of the ODUkP/RSn_A is similar to the behaviour of the ODUk/ETH_A but the RSn CTP object class is

not defined in UML and the SDH_RSn client type is also experimental.

VI.1 Client ODU over server ODU adaptation functions

These adaptation functions allow multiplexing multiple client ODU connections (e.g., LO ODUj or

ODUk) over a server ODU trail (e.g., HO ODUk or ODUCn respectively).

The EMF creates this adaptation function, together with its underlying ODUP_TT, when a server

ODU TTP is created with the oduType, clientType and mappingType attributes configured as

described in Table VI.1 above.

There are three types of such adaption functions, defined in [ITU-T G.798]:

– ODUkP/ODU[i]j_A, defined in clause 14.3.9 of [ITU-T G.798], which, from a

management perspective, can be further classified as:

• ODUkP/ODUj, which supports only one type of client ODUj (see Appendix VI.1.1);

• ODU3P/ODU12 which can support both ODU1 and ODU2 client ODUj types over an

ODU3 server ODUk (see Appendix VI.1.2);

– ODUkP/ODUj-21_A, defined in clause 14.3.10 of [ITU-T G.798], which can support

different client ODUj (j<k) types (see Appendix VI.1.3);

– ODUCnP/ODUk_A, defined in clause 14.3.16, which can support different ODUk types

(see Appendix VI.1.4).

These adaptation functions separate the client specific processes from other processes and allow the

EMF creating/deleting client specific processes when the corresponding client ODU CTPs are

created/deleted.

The relationship between the server ODU TTP and its client ODU CTPs is shown by the UML

diagram of Figure VI.1:

Rec. ITU-T G.875 (06/2020) 59

Figure VI.1 – Server ODU TTP and client ODU CTP relationships

It is worth noting that a server ODU TTP instance can support zero or more client ODU CTP

instances (as defined by the ServerOduBiSupportsClientOduBi association). Therefore, client ODU

CTP instances can be created/deleted independently after the server ODU TTP instance has been

created and, in particular, the server ODU TTP instance can be created with no client ODU CTP

instances.

VI.1.1 ODUkP/ODUj_A (clause 14.3.9 of [ITU-T G.798])

The EMF creates this adaptation function, together with its underlying ODUkP_TT, when a server

ODU TTP instance is created with the oduType, clientType and mappingType attributes configured

as described in Table VI.1. Figure VI.2 shows the ODUkP/ODUj_A adaptation function.

Figure VI.2 – ODUkP/ODUj_A

When the server ODU TTP instance is created with an oduType equal to ODU3, the EMF creates

either an ODU3P/ODU1_A, an ODU3P/ODU2_A or an ODU3P/ODU12_A, based on the OTN NE

hardware capabilities.

This clause describes only the specific behaviour of the ODU3P/ODU1_A or the

ODU3P/ODU2_A, which are created when the hardware is capable of supporting only client ODUj

type connections (either only ODU1 or only ODU2). The specific behaviour of the

ODU3P/ODU12_A is described in clause VI.1.2.

60 Rec. ITU-T G.875 (06/2020)

When the server ODU TTP is created with no client ODU CTPs, the EMF creates the

ODUkP/ODUj_A function with no client-specific processes. The TxMSI and ExMSI values are set

by the ODUkP/ODUj_A function, as described in Tables 14-25 and 14-27 of [ITU-T G.798]. All

the OPUk timeslots are empty (e.g., set to all zeros).

The EMF creates, within the ODUkP/ODUj_A function, an ODUj_CP together with its client

specific processes, when a client ODU CTP instance, with oduType equal to ODUj, is created over

the server ODU TTP instance.

The (ODUj) client ODU CTP instance is either attached to an ODUk SN instance (as defined by the

OdukSnAggregatesOduCtp association) or connected to a peer ODU CTP instance (as defined by

the OduCtpHasPeerOduCtp association), depending on whether the OTN NE supports or not

connectivity flexibility at the ODUj layer, as described in Appendix VII.1.1 and VII.1.2,

respectively.

VI.1.2 ODU3P/ODU12_A (clause 14.3.9 of [ITU-T G.798])

The EMF creates this adaptation function, together with its underlying ODU3P_TT, when a server

ODU TTP instance is created with the oduType, clientType and mappingType attributes configured

as described in Table VI.1 and the hardware is capable of supporting both ODU1 and ODU2 client

ODU connections over the server ODU. Figure VI.3 shows the ODU3P/ODU12_A adaptation

function.

Figure VI.3 – ODU3P/ODU12_A

When the server ODU TTP is created with no client ODU CTPs, the EFM creates the

ODU3P/ODU12_A function with no client-specific processes and configures the MI_TxMSI as

described in clause 19.4.1.2 of [ITU-T G.709]. All the OPUk timeslots are empty (e.g., set to all

zeros).

The EMF creates, within the ODU3P/ODU12_A, an ODU2_CP, or an ODU1_CP, together with its

client specific processes, when a client ODU CTP instance, with oduType equal to ODU2 or,

respectively, with oduType equal to ODU1, is created over the server ODU TTP instance. The EMF

also re-configures the MI_TxMSI and configures the MI_ExMSI[p], associated with the ODUj_CP,

or the ODUi_CP respectively, as described in clause 19.4.1.2 of [ITU-T G.709].

The (ODU1 or ODU2) client ODU CTP instance is either attached an ODUk SN instance (as

defined by the OdukSnAggregatesOduCtp association) or connected to a peer ODU CTP (as

defined by the OduCtpHasPeerOduCtp association), depending on whether the OTN NE supports or

not connectivity flexibility at the ODU1/ODU2 layer, are described in Appendices VII.1.1 and

VII.1.2, respectively.

Rec. ITU-T G.875 (06/2020) 61

VI.1.3 ODUkP/ODUj-21_A (clause 14.3.10 of [ITU-T G.798])

The EMF creates this adaptation function, together with its underlying ODUkP_TT, when a server


described in Table VI.1. Figure VI.4 shows the ODUkP/ODUj-21_A adaptation function.

Figure VI.4 – ODUkP/ODUj-21_A


ODUkP/ODUj-21_A with no client-specific processes and configures the MI_TxMSI to the value

that indicates that all the OPUk timeslots are Unallocated, as described in clauses 19.4.1.4, 19.4.1.5

and 19.4.1.6 of [ITU-T G.709].

The EMF creates, within this adaptation function, an ODUj_CP, together with its client specific

processes, when a client ODU CTP is created, with the odType set to ODUj, over the server ODU

TTP. The EMF also re-configures the MI_TxMSI and configures the MI_ODUType_Rate[p], the

MI_ODUType[p], the MI_Nominal_Bitrate_and_Tolerance[p] and the MI_ExMSI[p], associated

with the ODUj _CP, as described in clauses 19.4.1.4, 19.4.1.5 and 19.4.1.6 of [ITU-T G.709] and in

clause 14.3.10 of [ITU-T G.798].

The (ODUj) client ODU CTP is either attached to an ODUk SN (as defined by the

OdukSnAggregatesOduCtp association) or connected to a peer ODU CTP (as defined by the

OduCtpHasPeerOduCtp association), depending on whether the OTN NE supports or not

connectivity flexibility at the ODUj layer, are described in Appendices VII.1.1 and VII.1.2,

respectively.

VI.1.4 ODUCnP/ODUk_A (clause 14.3.16 of [ITU-T G.798])

The EMF creates this adaptation function, together with its underlying ODUCn_TT, when a server


described in Table VI.1. Figure VI.5 shows the ODUCnP/ODUk_A adaptation function.

62 Rec. ITU-T G.875 (06/2020)

Figure VI.5 – ODUCnP/ODUk_A


ODUCnP/ODUk_A with no client-specific processes and configures the MI_TxMSI to the value

that indicates that all the OPUCn timeslots are Unallocated, as described in clause 20.4.1.1 of

[ITU-T G.709].

The EMF creates, within this adaptation function, an ODUk_CP, together with its client specific

processes, when a client ODU CTP is created (with oduType equal to ODUk) over the server ODU

TTP. The EMF also re-configures the MI_TxMSI and the MI_ExMSI and configures the

MI_Nominal_Bitrate_and_Tolerance[p], associated with the ODUk_CP, as described in

clause 20.4.1.1 of [ITU-T G.709] and in clause 14.3.16 of [ITU-T G.798].

The (ODUk) client ODU CTP is either attached to an ODUk SN (as defined by the

OdukSnAggregatesOduCtp association) or connected to a peer ODU CTP (as defined by the

OduCtpHasPeerOduCtp association), depending on whether the OTN NE supports or not

connectivity flexibility at the ODUj layer, are described in Appendices VII.1.1 and VII.1.2,

respectively.

In case this adaptation function is created in an OTN NE with no connectivity flexibility at the

client ODUk layer (e.g., a 3R muxponder), each client ODU CTP, when created (with oduType set

to ODUk), is connected to a peer ODU CTP with fixed connectivity, as described in

Appendix VI.1.2, and Figures VII.6 and VI.6.

Figure VI.6 – ODUCn/ODUk_A with peer fixed connectivity

VI.2 ODU to packet adaptations

These adaptation functions allow carrying packets (e.g., MPLS-TP or Ethernet) over a server layer

ODUk trail.

There are two such adaption functions:

Rec. ITU-T G.875 (06/2020) 63

• ODUkP/MT_A, defined in clause 14.3.19 of [ITU-T G.798] (see Appendix VI.2.1);

• ODUkP/ETH_A, defined in clause 14.3.11 of [ITU-T G.798] (see Appendix VI.2.2).

VI.2.1 ODUkP/MT_A (clause 14.3.19 of [ITU-T G.798])

This adaptation functions allows multiplexing multiple client MPLS-TP connections over a server

layer ODUk trail.

Like the ODUkP/ODU[i]j_A, this adaptation function separates the client specific processes and

allows the EMF creating/deleting its client specific processes when the corresponding client

MPLS-TP CTP object class instances are created/deleted. Figure VI.7 shows a server ODU TTP

supporting client MPLS-TP CTP.

Figure VI.7 – Server ODU TTP supports client MPLS-TP CTP

NOTE – MPLS-TP model is defined in [ITU-T G.8152]

The EMF creates this adaptation function, together with the corresponding ODUkP_TT, when a

server ODUk TTP instance is created with the attributes set as described in Table VI.1. Figure VI.8

shows the ODUkP/MT_A adaptation function.

Figure VI.8 – ODUkP/MT_A

64 Rec. ITU-T G.875 (06/2020)

When the ODUk TTP is created with no client MPLS-TP CTPs, no client-specific processes are

created within the ODUkP/MT_A functions by the EMF: the ODUkP/MT_A_So sends GFP idle

frames since there are no MPLS packets to transmit at it input MT_CPs.

The EMF creates, within this adaptation function, an MT_CP, together with its client specific

processes, when a client MPLS-TP CTP is created over the server ODUk TTP. Further details are


VI.2.2 ODUkP/ETH_A (clause 14.3.11 of [ITU-T G.798])

This adaptation function is used to expose a server layer ODUk trail as an Ethernet interface to the

ETH layer network and therefore supports only on ETH CP.

Even if this adaptation function, shown in Figure VI.10, does not separate the client specific

processes from the other processes, the server ODUk TTP can be created with no client ETH CTP.

Figure VI.9 shows a server ODU TTP supporting a client ETH CTP.

Figure VI.9 – Server ODU TTP supports client ETH CTP

NOTE – Ethernet model is defined in [ITU-T G.8052]

The EMF creates this adaptation function shown in Figure VI.10, together with the corresponding

ODUkP_TT, when a server ODU TTP instance is created with the attributes set as described in

Table VI.1.

Figure VI.10 – ODUkP/ETH_A

Rec. ITU-T G.875 (06/2020) 65

When the ODUk TTP is created without its client ETH CTP, the ODUkP/ETH_A_So will only

send GFP idle or client management frames since there are no ETH frames to transmit at its input

ETH_CP. The default values, defined in Table 8-3 of [ITU-T G.8051], are used for the MI_ signals

of the ETH client specific processes (including the GFP-CSF configuration).

When the client ETH CTP is created over the server ODUk TTP, the EMF re-configures the

MI_ signals of the ETH client specific processes within this adaptation function: further details are


VI.3 ODU to CBR, ETC and ERS clients

These adaptation functions allow carrying digital data streams (e.g., CBR, ETC and ERS) over a

server layer ODUk trail.

There are multiple types of such adaption functions as described in Table VI.1 which are modelled

by the ODU-Client CTP object class.

Since these adaptation functions do not separate the client specific processes from other processes,

the server ODUk TTP and the client ODU-Client CTP object class instances should be created

together, as defined by the ServerOduTtpSoSupportsClientOduClientCtpSo,

ServerOduTtpSkSupportsClientOduClientCtpSk and

ServerOduTtpBiSupportsClientOduClientCtpBi associations. Figure VI.11 shows a server ODU

TTP supporting client ODU-client CTP.

Figure VI.11 – Server ODU TTP supports client ODU-client CTP

The EMF creates one of these adaptation functions (e.g., an ODUkP/CBR-g_A), together with its

underlying ODUkP_TT, when a server ODU TTP instance is created with the attributes set as

described in Table VI.1.

66 Rec. ITU-T G.875 (06/2020)

Figure VI.12 – ODUkP/CBRx-g_A

Since there is no connectivity flexibility in the CBR, ETC and ERS layers, the client CP port of this

adaptation function, shown in Figure VI.11 (e.g., ODUkP/CBR-g_A) has fixed connectivity to a

peer client CP port of another adaptation function (e.g., OTSi(G)/ETCy). Figure VI.13 shows

ODUkP/CBRx-g_A with peer fixed connectivity.

Figure VI.13 – ODUkP/CBRx-g_A with peer fixed connectivity

The modelling of this fixed connectivity is for further study.

Also the modelling of the Media Element as well as of the server specific processes of the

OTSi(G)/ETCy_A are currently under study in ITU-T.

Rec. ITU-T G.875 (06/2020) 67

Appendix VII

Overview of the OTU/ODU adaptation functions configuration


These adaptation functions allow carrying a client ODU (e.g., ODUk or ODUCn) over its server

layer OTU trail (e.g., OTUk or OTUCn).

There are two of such adaption functions:

• OTUk/ODUk, as defined in clause 13.1.1 (see Appendix VII.1);

• OTUCn/ODUCn, as defined in clause 13.1.1 (see Appendix VII.2).

Since these adaptation functions do not separate the client specific processes from other processes,

the server OTU TTP and the client ODU CTP object class instances should be created together, as

described by the UML diagram shown in Figure VII.1.

Figure VII.1 – Server OTU and client ODU relationship

Note – Figure VII.1 shows the associations between server OtuTtp & client OduCtp. It also shows the association between server

OduTtp & client OduCtp.

The _odu_connectionterminationpointbidirectional mandatory attribute of the server OTU TTP

references to the client ODU CTP and therefore both object class instances should be created

together.

Transient conditions (e.g., when only one object class has been created) as well as transaction

mechanisms to create both object class instances at the same time are for further study.

Within an OTN network element (NE), the EMF creates a specific OTU/ODU_A atomic function,

defined in [ITU-T G.798], when a server OTU TTP and its client ODU CTP object class instances

are created, based on the configured otuType and oduType, as summarized in Table VII.1.

68 Rec. ITU-T G.875 (06/2020)

Table VII.1 – Summary of the OTU/ODU_A atomic functions

otuType oduType G.798 adaptation function Subclause of this

appendix

OTU1 ODU1 OTUk/ODUk_A (k=1) 13.3.1 VII.1




OTUCn ODUCn OTUCn/ODUCn_A 13.3.1 VII.2

VII.1 OTUk/ODUk_A (clause 13.3.1 of [ITU-T G.798])

The EMF creates this adaptation function, shown in Figure VII.2, (setting the MI_Mode to the value

OPERATIONAL), together with the corresponding OTUk_TT, when a server OTU TTP and its

client ODU CTP instances are created with the otuType and the oduType attributes configured as

described in Table VII.1.

Figure VII.2 – OTUk/ODUk_A

Conditions triggering to create of these atomic functions (setting the MI_Mode to the value

TRANSPARENT) as part of compound functions are also for further study.

VII.1.1 Flexible connectivity configuration in the ODUk layer

Figure VII.3 shows OTUk/ODUk_A with ODU_C flexible connectivity. In the case where the OTN

NE supports connectivity flexibility at the client ODUk layer, the EMF also connects its ODUk_CP

port, of the OTUk/ODUk_A functions, to the ODU_C atomic function, defined in clause 14.1 of

[ITU-T G.798].

Rec. ITU-T G.875 (06/2020) 69

Figure VII.3 – OTUk/ODUk_A with ODU_C flexible connectivity

The ODU_C atomic function allows the EMF configuring its matrix connection when the

corresponding ODUk SNC is created/deleted.

The relationship between ODU CTP, ODUk SN and ODUk SCN object classes is shown in the

UML diagram of Figure VII.4.

Figure VII.4 – Relationship between ODUk CTP, ODUk SN and ODUk SNC

The cardinality of the OdukSnAggregatesOduCtp association indicates that an ODU CTP instance,

with oduType equal to ODUk, should be attached to an ODUk SN instance when created within an

OTN NE supporting connectivity flexibility in the ODUk layer.

VII.1.2 Fixed peer connectivity between ODU CTPs

In the case where the OTN NE does not support connectivity flexibility at the client ODUk layer

(e.g.,a 3R regenerator), the ODUk_CP port, of the OTUk/ODUk_A function, can have a fixed

connectivity to a peer ODUk_CP port of another OTUk/ODUk_A function as shown in

Figure VII.5.

70 Rec. ITU-T G.875 (06/2020)

Figure VII.5 – OTUk/ODUk/A with peer fixed connectivity

Since there is no process that generates ODUk replacement signals for open connection, the two

peer ODUk_CP ports as well as their client specific processes and their adaptation functions are

created together.

The relationship between peer ODU CTPs with fixed connectivity is shown by the UML diagram of

Figure VII.6.

Figure VII.6 – Relationship between peer ODU CTPs

The cardinality of the OduCtpHasPeerOduCtp indicates that the two peer ODU CTP instances

should be created together.

It is worth noting that some ODU CTPs may have requirements to be created together with their

server layer TTPs.

Transient conditions (e.g., when only one object class has been created) as well as transactions to

create all these object classes at the same time are for further study.

VII.1.3 Fixed termination between an ODU CTP and an ODU TTP

In the case where the OTN NE does not support connectivity flexibility at the client ODUk layer

(e.g., an OTN interface termination), the ODUk_CP port, of the OTUk/ODUk_A functions can

have fixed connectivity with an ODUk_TCP port, of an ODUkP_TT as shown in Figure VII.7.

Rec. ITU-T G.875 (06/2020) 71

Figure VII.7 – OTUk/ODUk/A with fixed termination

Since there is no process that generates ODUk replacement signals for open connection, the

OTUk/ODUk_A and ODUkP_TT functions are created together.

The relationship between terminated ODU CTP and ODU TTP with fixed connectivity is shown by

the UML diagram of Figure VII.8.

Figure VII.8 – Terminated and mapped ODU CTP

The cardinality of the ConnectivityPointerForTerminatedAndMappedOduCtp indicates that the

ODU CTP and ODU TTP object class instances should be created together.

It is worth noting that some ODU CTPs may have requirements to be created together with their

server layer TTPs.

It is also worth noting that some ODU TTPs may have requirements to be created together with

their client layer CTPs, following the procedures described in Appendices VI.1, VI.2 and VI.3:

depending on the type of ODUk client layer other object class instances may need to be created

together with the OTU TTP, ODU CTP and ODU TTP.

Transient conditions (e.g., when only one object class has been created) as well as transactions to

create all these object classes at the same time are for further study.

VII.2 OTUCn/ODUCn_A (clause 13.3.1 of [ITU-T G.798])

The EMF creates this adaptation function, shown in Figure VII.9, (setting the MI_Mode to the value

OPERATIONAL) together with the corresponding OTUCn_TT, when a server OTU TTP and its

client ODU CTP instances are created with the otuType and the oduType attributes configured as

described in Table VII.1.

72 Rec. ITU-T G.875 (06/2020)

Figure VII.9 – OTUCn/ODUCn_A

Conditions triggering to create of these atomic functions (setting the MI_Mode to the value

TRANSPARENT) as part of compound functions are also for further study.

Since there is no connectivity flexibility in the ODUCn layer, this adaptation function can only be

created with fixed connectivity.

In case this adaptation function is created in an OTN NE with peer fixed connectivity (e.g.,a 3R

regenerator), the ODU CTP instance (with oduType set to ODUCn) should be created together with

its peer ODU CTP instance, as described in Appendix VI.1.2, Figure VII.5 and Figure VII.6.

In the case where this adaptation function is created in an OTN NE with fixed termination (e.g., an

OTN interface termination), the ODU CTP and TTP instances (with oduType set to ODUCn)

should be created together, as described in Appendix VI.1.3, Figure VII.7 and Figure VII.8.

Rec. ITU-T G.875 (06/2020) 73

Bibliography

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

[b-ONF TR-515] ONF TR-515_Papyrus-Guidelines <https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2018/08/TR-515_Papyrus_Guidelines_v1.3-1-1.pdf > <https://community.opensourcesdn.org/wg/EAGLE/document/171>

[b-ITU-T G-Sup.56] ITU-T G-series Recommendations – Supplement 56 (2016), OTN transport of

CPRI signals.

https://www.eclipse.org/papyrus/

https://community.opensourcesdn.org/wg/EAGLE/document/171

Printed in Switzerland Geneva, 2020

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

itu-t rec. g.875 (06/2020) optical transport network

Documents