Child pages
  • Contributions

INTERNATIONAL TELECOMMUNICATION UNION

TELECOMMUNICATION
STANDARDIZATION SECTOR

STUDY PERIOD 2017-2020

SG15-TD213R1/WP3

STUDY GROUP 15

Original: English

Question(s):

14/15

Geneva, 29 January -9 February 2018  

TD

Source:

Editor G.media-mgmt

Title:

Draft Recommendation G.media-mgmt (version 0.02)

Purpose:

Discussion

Contact:

Qilei Wang
ZTE Coporation
P. R. China
 

Tel: +86-25-88016576
E-mail: wang.qilei@zte.com.cn

Contact:

Yuji Tochio
Fujitsu
Japan
 

Tel: +81-44-754-8829
Fax:
E-mail: tochio@jp.fujitsu.com

 

Keywords:

G.media-mgmt; Media

Abstract:

This document provides the 0.02 draft of Recommendation ITU-T G.media-mgmt. At the Q14/15 Feb. 2018 Plenary Meeting, it was agreed to take C466 and C521r1 as input to G.media-mgmt and to post it as a TD213r1/WP3 after the January 2018 SG15 plenary meeting.

 

 

 

Document history :

Version

Date

Description

0.01

WD14-34 (12/2017)

TD/WP3 (1/2018)

Initial version v0.01 provides the Recommendation outline.

 

0.02

TD213r1 (2/2018)

- Incorporate the input from C466 and C521r1.

- Update the UML model in clause 8 with Eclipse Oxygen v4.7.0 and Papyrus v3.2.0


Draft Recommendation ITU-T G.media-mgmt

Management Requirement and Information Model for Media

Summary

This Recommendation describes the management requirement and information model for media that is based on G.7711 object classes. Management of media is independent of layer information in optical signals supported by the media, but re-use of the G.7711 object classes provides consistency among interfaces that are refactored from the model. A purpose specific IM view of media can enable configuration of media even in the absence of optical signals. Being based on the common IM, an information model for media can provide consistent operation, administration, maintenance and provisioning of transport networks.

[Note: quoted from Annex G, TD28/P]

Keywords

1 Scope

This Recommendation describes the management requirement and information model for media that is based on G.7711 object classes. Management of media is independent of layer information in optical signals supported by the media, but re-use of the G.7711 object classes provides consistency among interfaces that are refactored from the model. A purpose specific IM view of media can enable configuration of media even in the absence of optical signals. Being based on the common IM, an information model for media can provide consistent operation, administration, maintenance and provisioning of transport networks.

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 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.7711] Recommendation ITU-T G.7711 (2018), Generic protocol-neutral information model for transport resources.

[ITU-T G. media ] Draft Recommendation ITU-T G.media ( 201x ), Architecture of optical media

 

3 Definitions

3.1 Terms defined elsewhere

This Recommendation uses the following terms defined elsewhere:

 

3.2 Terms defined in this Recommendation

This Recommendation defines the following terms:

 

4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:

5 Conventions

 

6 Media management functions

 

6.1 Media management functions

[Editor note: The text should be provided based on G.media. Clause 7.1 of C.521r1 will be candidate text for input]

6.2 Configuration Management

Editor note: t ext is needed.

 

6.3 Fault Management

Editor note: t ext is needed.

 

6.4 Performance Management

For further study.

 

6.4 Account Management

For further study.

 

6.6 Security Management

For further study.

 

7. Media management model

7.1. Model Overview

[ Editor note: to be added later]

7.2. Model attributes

7.2.1. Directionality

As described in clause xxx of G.media , a media channel may support the propagation of signals in both directions (e.g. a fibre), or in only one direction (e.g. an amplifier).

[ Editor note: need to realign with G.media. ]

We should refer to a media channel and the associated media ports that support the propagation of signals in both directions as “omni directional”. This will avoid confusion with the concept of bidirectional used in the digital layers where bidirectional is pair of unidirectional entities.

In the current information model (for the digital layers) we have the concepts of “source”, “sink” and “bidirectional”. Bidirectional entities are defined as a pair (source/sink) of unidirectional entities.

In some media elements (e.g. a media element that encompasses a circulator) the media channels between the media ports only support the propagation of a signal in one direction, i.e. the media channel is inherently unidirectional however the media ports are omni directional. This is illustrated in the figure 7-1 below.

7.2.2. Management representation of a media element

For the information model the media element, media channel and media port should be represented by a forwarding domain, forwarding construct (with a specification) and forwarding port respectively as illustrated below.

Figure 7-1 mapping the media functional model to the information model

The point to multipoint FC represents the set of forwarding ports that may be connected. The frequency slot and transfer parameters of a media channel (if present) between a pair of forwarding ports is provided by the FC spec (for each direction of propagation).

The case of a media element that inherently only supports unidirectional media channels (e.g. a media element that encompasses a circulator) is shown below.

Figure 7-2 Example of unidirectional media channels

The media channels may not always be present in a media element (e.g. a media element that encompasses a flexible grid capable filter). In this case the media element is configured by adding a FC spec to the FC. Existing media channels may be removed or modified by the deletion of modification of the FC spec. The case of a flexible grid capable filter with no media channels configured is shown below.

Figure 7-3 Media element with no media channels configured

In some media elements (e.g. a media element that encompasses a fixed grid filter) the media channels are always present and cannot be configured. In this case the FC spec is predefined and cannot be modified.

In other types of media element (e.g. a media element that encompasses an amplifier) the media channel is always present with a predefined frequency slot but the transfer parameters (e.g. gain) may be adjusted by modifying the transfer parameters of the FC spec.

As described in clause xxx of G.media , more than one media channel may exist between a pair of media ports. One example of this is an amplifier that support the C-band and the L-band, or an OMS media link that is supported by such amplifiers. This is illustrated in figure 7-4 below.

Figure 7-4: Example of a media element that encompasses a split band amplifier or OMS media link

Some media elements may have restricted connectivity in that it may not be possible to configure media channels between all of the media ports on the media element. In this case the FD (that represents the media element) will support two or more FCs. This is illustrated in the figure 7-5 below.

Figure 7-5 Media element with restricted connectivity.

7.2.3. Concatenation of media channels

A media channels is defined in G.media as a topological construct that represents both the path through the media and the resource (frequency slot) that it occupies and may be a serial concatenation of multiple media channels each with its own frequency slot.

Media channels are encompassed by media elements and we have a direct binding between the media ports on adjacent media elements. This requires the information model support a direct relationship between the forwarding ports on forwarding domains.

G.media states that a media element cannot encompass another media element. The concatenation of media functions results in a larger (opaque) media element. However, from a management control perspective it is necessary to allow a FD that represents a media element to be contained within another FD and the sequence of the contained FDs/FCs should be visible (as with a “normal” FD).

When a media element that contains omni directional media channels is bound to a media element that only supports unidirectional propagation the concatenated media channel becomes unidirectional.

7.2.4. Bandwidth allocation

When a “wide” frequency slot (e.g. those in an OMS media link) is used to support more than on network media channel it is necessary to track the portions of the spectrum that have been allocated. The spectrum allocation is not visible in the media (media channels have no hierarchy). However, from a management/control perspective it may be useful to model spectrum allocation as though it is hierarchical. i.e. a “wide” media channel may support (contain) multiple “narrower” media channels. It may also be necessary to track the “types” of signals that will be assigned to particular media channels since signals that use different modulation schemes (e.g. phase modulation and amplitude modulation) may require a guard band between them to mitigate the effects of destructive interference.

Neither the spectrum allocation nor the intended signal type are visible to the media element, however, it is essential that the management system can track these allocations.

7.2.5. Higher level abstractions

The normal mode of operation for a network is to manage bidirectional connections which are supported by a pair of unidirectional connections. A typical network implementation uses a pair of fibres to support bidirectional signals, one for each direction of propagation. From this perspective, it would be useful to support bidirectional media FDs/FCs which are supported by (lower in the recursion) unidirectional FCs. Some of these FCs may be inherently unidirectional, or the directionality may be “assigned” by the management system, or “imposed” by the binding to other media FD/FCs as described above. It would be useful to provide in the model a bidirectional port and FC spec that are supported by a pair of omni or unidirectional ports or FC specs respectively. The figure 7-6 below shows an example of a bidirectional FC (with bidirectional ports) that is supported by a pair of omni directional FC specs each with omni directional FC ports.

Figure 7-6 Bidirectional representation

In this example a higher level manager has chosen to use the top FC for signals being propagated between ports 1 2, 1 3 and 1  The lower FC is used for signals being propagated 6 5, 7   5 and 8 5. Bidirectional forwarding port A is supported by omni directional forwarding ports 1 and 5 and the bidirectional FC spec between forwarding ports A and B is supported by the frequency slot and transfer parameters of the 1 2 FC spec (the 2 1 frequency slot and transfer parameters are not used) and the frequency slot and transfer parameters of the 6 5 FC spec (the 6   5 frequency slot and transfer parameters are not used). Similarly, for the other bidirectional FC specs.

7.2. 6 . Management of OTSiA connections

According to the description of OTSiA in G.media , it should be noted that the request for an OTSiA connections is normally for a bidirectional connection, typically two fibres are used, one for each direction of propagation, so the request for an OTSiA connection must be mapped into “pairs” of media channels (one for each direction of propagation).

7.2. 7 . Optical signal maintenance entities

Optical signal maintenance entities are described in clause xxx of G.media ”, that the the end points of the OMS OSME and OTS OSME may be encompassed in a media element.

As described in clause 7.2.2, the FD, FC and FC spec are used to represent the media element and the media channels that it contains. The FD will need to be extended to also provide the OTS and OMS LOS indications. The extension to the FD to support the OTS and OMS LOS should take into account the possibility of the need to support more sophisticated information as described in the following (informative) note from clause 8.4.3:

“NOTE – The implementation of the OTS OPM or OMS OPM may include the ability to detect which frequency slots have an active OTSi. This capability is particularly useful when the frequency slot of the OPM matches the effective frequency slot of a network media channel. The information from this capability may be used for fault isolation in the case where a fault occurs in a frequency selective component and therefore not all of the OTSi being carried by the OTS or OMS media link are impacted. Further details of other optical monitoring capabilities are provided in [ITU-T G.697].”

 

8. UML model file for Media

This clause contains the information model files with data dictionary and the companion profile fil s e specified using the “Papyrus” modelling tool.


NOTE – The ITU-T G.media-mgmt 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, one will need to install the open source Eclipse software and the Papyrus tool, which are available at [b-Eclipse-Papyrus]. The installation guide for Eclipse and Papyrus can be found in [b-IISOMI-515].

Appendix I

xxx

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

 

Bibliography

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

[b-IISOMI-515] IISOMI-515_Papyrus-Guidelines.docx

_______________________