international telecommunication union sg15 -td583 … · 2020. 10. 5. · - 3 - sg15-td583-r1/plen...
Post on 15-Mar-2021
8 Views
Preview:
TRANSCRIPT
INTERNATIONAL TELECOMMUNICATION UNION
TELECOMMUNICATION
STANDARDIZATION SECTOR
STUDY PERIOD 2017-2020
SG15-TD583-R1/PLEN
STUDY GROUP 15
Original: English
Question(s): 14/15 E-meeting, 7–18 September 2020
TD
Source: Editors G.8152.2
Title: Draft new Recommendation G.8152.2 “Resilience Information/Data Models for
MPLS-TP Network Element” for consent
Purpose: Proposal
Contact: Weiqiang CHENG
China Mobile Communications
Corporation
China
Tel: +86-10-15801696688-33651
Fax: +86-10-63601087
E-mail: chengweiqiang@chinamobile.com
Contact: Ying ZHANG
China Information Communication
Technologies Group
China
Tel: +86 13476088110
Email: zhangy@fiberhome.com
Keywords: MPLS-TP, Information model, Resilience, UML, Data model, YANG
Abstract: This document contains the editor draft of new Recommendation G.8152.2
“Resilience Information/Data Models for MPLS-TP Network Element”, v0.06 for
consent.
Document history:
Version Date Description
0.01 WD1214-20(01/2019) The first draft new Recommendation G.8152.2, update clause
6 based on wd1214-36
0.02 WD14-21(04/2019)
Xi’an
TD378/3 (7/2019)
Geneva
Add object classes, attributes and operations of linear
protection group in clause 7, based on wd14-38 and wd14-39
- 2 -
SG15-TD583-R1/PLEN
Version Date Description
0.0.3 WD14-21(7/2019)
Geneva
Updates:
(1) Add description for figure 7.1.1-2 based on C1441 clause
2.1.
(2) Add an appendix I.1 to describe 1+1/1:1 linear protection
example based on C1441 clause 2.2.
(3) Split clause 7.1 into two sub clauses, 7.1.1 for linear
protection, 7.1.2 for shared ring protection
(4) Add object classes and relations for shared ring protection
in 7.1.2 based on C1304 clause 2.1.
(5) Add an appendix I.2 to describe the ring protection
examples. And add I.2.1 to describe the wrapping
protection group based on C1304 clause 2.2.1.
0.04 WD14-16 (9/2019)
Goteborg
TD487/WP3 (1/2020)
Updates:
(1) Add appendix I.2.2 to describe the short-wrapping and
appendix I.2.3 to describe the steering based on wd14-29.
(2) In Appendix I.2, revise the name in the text to make sure
that they’re the same within the figures according to the
discussion.
(3) Add some description to Figure 7.1.2-1 according to the
discussion.
0.05 WD14-22 (2/2020)
TD487R1/WP3
(2/2020)
Updates:
(1) Per C1884: change Appendix I.2 to Annex A, with
adjustment as noted in the discussion. Add a sentence
after the last paragraph of clause 7.1.2 according to C1884
(2) Per C1885: Clause 7.1.1 “Linear protection” object
classes & relations and clause 7.2.1 “Linear protection”
attributes and operations.
(3) Per C1886: Clauses 3 and 4, with adjustment as noted in
the discussion.
(4) Per C1893: Clause 7.1.2 “Shared ring protection” object
classes & relations and clause 7.2.2 “Shared ring
protection” attributes and operations.
0.06 CD09(6/2020) v0.06-
E1
(1) Delete Pseudowire Redundancy in table 6.1-1
(2) Update figure 7.1.1-3, for each object class, change the
appearance-Qualified name from None to full. so that it
can easily know the object class from which
Recommendation.
(3) Update figure 7.1.1-4, for each object class, change the
appearance-Qualified name from None to full.
(4) Update figure 7.1.2-3, for each object class, change the
appearance-Qualified name from None to full.
(5) Update figure 7.1.2-4, for each object class, change the
appearance-Qualified name from None to full.
(6) Add UML file to clause 7.3
- 3 -
SG15-TD583-R1/PLEN
Version Date Description
CD09r1 (6/2020)
v0.06-E2
(1) Accept all the revision history.
(2) Update as per contribution CD11r1.
CD09r3 (7/2020)
v0.06-E3
(1) Update Clause 7 resilience UML model according to
CD10r5 and CD10r6:G.8152.2 should has its own UML
model, it’s pruned and refactored from core model and
G.8152.2.
(2) Add a comment for G.8152.2 Fc and FcPort object classes
(need to be refactored into UML artifacts which supposed
to be re-engineered from the IETF mpls-base & mpls-
static RFC yang, which is yet to be finalized.) according
to CD10r5 and CD10r6.
(3) Update yang model according to the update (1) and (2).
0.07 WD14-57 (9/2020)
TD583R1/PLEN
(9/2020)
(1) Update UML model and yang model according to WD14-
16r2. (2) Add IETF RFC 6991, RFC 7950, RFC 8340, RFC8342 as
reference in clause 2.
- 4 -
SG15-TD583-R1/PLEN
Table of Contents
1 Scope ............................................................................................................................................ 6
2 References .................................................................................................................................... 6
3 Definitions .................................................................................................................................... 7
3.1 Terms defined elsewhere ....................................................................................................... 7
3.1.1 1+1 protection architecture [ITU-T G.808] ................................................................ 8
3.1.2 1:n protection architecture [ITU-T G.808] ................................................................. 8
3.1.3 forced switch [ITU-T G.808] ...................................................................................... 8
3.1.4 hold-off time [ITU-T G.808] ...................................................................................... 8
3.1.5 manual switch [ITU-T G.808] .................................................................................... 8
3.1.6 protection [ITU-T G.808] ........................................................................................... 8
3.1.7 protection group [ITU-T G.808] ................................................................................. 8
3.1.8 signal degrade (SD) [ITU-T G.806] ............................................................................ 8
3.1.9 signal fail (SF) [ITU-T G.806] .................................................................................... 8
3.1.10 switch [ITU-T G.808] ............................................................................................... 8
3.1.11 unidirectional protection switching [ITU-T G.780] .................................................. 8
3.1.12 wait-to-restore time [ITU-T G.808] .......................................................................... 8
3.1.13 clear: [ITU-T G.808] ................................................................................................. 8
3.1.14 exercise signal: [ITU-T G.808] ................................................................................. 8
3.1.15 server signal fail (SSF): [ITU-T G.806].................................................................... 8
3.1.16 steering: [ITU-T G.808] ............................................................................................ 8
3.1.17 wrapping: [ITU-T G.808] ......................................................................................... 8
3.2 Terms defined in this Recommendation ................................................................................ 8
4 Abbreviations and acronyms ........................................................................................................ 8
5 Conventions ................................................................................................................................. 9
5.1 Information modelling conventions ....................................................................................... 9
5.1.1 UML modelling conventions ...................................................................................... 9
5.1.2 Model Artefact Lifecycle Stereotypes conventions .................................................... 9
5.1.3 Forwarding entity terminology conventions ............................................................... 9
5.1.4 Conditional package conventions ............................................................................... 9
5.1.5 Pictorial diagram conventions ..................................................................................... 9
5.2 Equipment function conventions ........................................................................................... 9
5.3 Conventions defined in this Recommendation ...................................................................... 9
6 MPLS-TP Resilience Functions ........................................................................................................ 9
6.1 Linear Protection Functions ................................................................................................... 9
- 5 -
SG15-TD583-R1/PLEN
6.2 Ring Protection Functions .................................................................................................... 10
7 MPLS-TP Resilience Information Model ....................................................................................... 10
7.1 Required Object Classes and relations ................................................................................. 10
7.1.1 Linear protection ....................................................................................................... 10
7.1.2 Shared ring protection ............................................................................................... 13
7.2 Required Attributes and Operations ..................................................................................... 16
7.2.1 Linear protection ....................................................................................................... 16
7.2.2 Shared ring protection ............................................................................................... 19
7.3 UML model files .................................................................................................................. 21
7.3.1 Linear protection ....................................................................................................... 21
7.3.2 Ring protection .......................................................................................................... 21
8 MPLS-TP Resilience Data Models ................................................................................................. 21
8.1 YANG Data Model .............................................................................................................. 21
8.1.1 Linear protection ....................................................................................................... 21
8.1.2 Ring protection .......................................................................................................... 22
8.2 Other Data Model................................................................................................................. 22
Annex A ............................................................................................................................................. 23
MSRP information model .................................................................................................................. 23
A.1 wrapping .............................................................................................................................. 25
A.3 Steering ............................................................................................................................... 29
A.2 short-wrapping .................................................................................................................... 33
Appendix I.......................................................................................................................................... 37
Linear protection examples ................................................................................................................ 37
I.1 1+1/1:1 cases ........................................................................................................................ 37
- 6 -
SG15-TD583-R1/PLEN
Recommendation ITU-T G.8152.2
Resilience Information/Data Models for MPLS-TP Network Element
Summary
This Recommendation specifies the resilience management information model and data models for
MPLS-TP Network Element (NE) as defined in [ITU-T G.8131] and [ITU-T G.8132]. The
information model is interface protocol neutral and specified using the Unified Modelling Language
(UML). The information model of this Recommendation is derived through pruning and refactoring
from the Recommendation [ITU-T G.7711/Y.1702] core information model and Recommendation
[ITU-T G.8152/Y.1375] foundation MPLS-TP NE information model. The data models are
interface protocol specific and translated from the information model with the assistance of
automated translation tooling. The specific interface protocols considered in this Recommendation
include, but not limited to, NETCONF/YANG.
Keywords
MPLS-TP, Information model, Resilience, UML, Data model YANG.
Introduction
<Optional – This clause should appear only if it contains information different from that in Scope
and Summary>
1 Scope
This Recommendation specifies the resilience information models and data models for MPLS-TP
transport Network Element (NE) to support specific interface protocols and specific management
and control functions. The information models are interface protocol neutral and derived through
pruning and refactoring from the [ITU-T G.7711] core information model and [ITU-T G.8152]
foundation MPLS-TP NE information model. The data models are interface protocol specific and
translated from these information models. The specific interface protocols considered include, but
not limited to, NETCONF/YANG. The specific management and control functions for resilience
covered by this Recommendation include the [ITU-T G.8131] MPLS-TP Linear protection
switching and [ITU-T G.8132] MPLS-TP Shared Ring protection switching.
The YANG modules of this Recommendation are aimed to be compatible with and when necessary
extend the relevant IETF base generic YANG modules for the [ITU-T G.8131] and [ITU-T G.8132]
resilience functions.
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/Y.1702 (3/2018), Generic protocol-neutral
information model for transport resources.
- 7 -
SG15-TD583-R1/PLEN
[ITU-T G.780] Recommendation ITU-T G.780/Y.1351 (07/2010), Terms and definitions
for synchronous digital hierarchy (SDH) networks.
[ITU-T G.806] Recommendation ITU-T G.806 (08/17), Characteristics of transport
equipment – Description methodology and generic functionality.
[ITU-T G.808] Recommendation ITU-T G.808 (11/2016), Terms and definitions for
network protection and restoration.
[ITU-T G.8131] Recommendation ITU-T G.8131/Y.1382 (7/2014), Linear protection
switching for MPLS transport profile.
[ITU-T G.8132] Recommendation ITU-T G.8132/Y.1383 (8/2017), MPLS-TP shared ring
protection.
[ITU-T G.8152] Recommendation ITU-T G.8152/Y.1735 (10/2018), Protocol-neutral
management information model for the MPLS-TP network element.
[IETF RFC 8227] RFC IETF RFC8227 (08/17), MPLS-TP Shared-Ring Protection (MSRP)
Mechanism for Ring Topology.
[IETF RFC 6991] RFC IETF RFC6991 (07/13), Common YANG Data Types.
[IETF RFC 7950] RFC IETF RFC7950 (08/16), The YANG 1.1 Data Modeling Language.
[IETF RFC 8340] RFC IETF RFC8340 (03/18), YANG Tree Diagrams.
[IETF RFC 8342] RFC IETF RFC8342 (03/18), Network Management Datastore Architecture
(NMDA).
3 Definitions
3.1 Terms defined elsewhere
This Recommendation uses the following terms defined elsewhere:
- 8 -
SG15-TD583-R1/PLEN
3.1.1 1+1 protection architecture [ITU-T G.808]
3.1.2 1:n protection architecture [ITU-T G.808]
3.1.3 forced switch [ITU-T G.808]
3.1.4 hold-off time [ITU-T G.808]
3.1.5 manual switch [ITU-T G.808]
3.1.6 protection [ITU-T G.808]
3.1.7 protection group [ITU-T G.808]
3.1.8 signal degrade (SD) [ITU-T G.806]
3.1.9 signal fail (SF) [ITU-T G.806]
3.1.10 switch [ITU-T G.808]
3.1.11 unidirectional protection switching [ITU-T G.780]
3.1.12 wait-to-restore time [ITU-T G.808]
3.1.13 clear: [ITU-T G.808]
3.1.14 exercise signal: [ITU-T G.808]
3.1.15 server signal fail (SSF): [ITU-T G.806]
3.1.16 steering: [ITU-T G.808]
3.1.17 wrapping: [ITU-T G.808]
3.2 Terms defined in this Recommendation
None.
4 Abbreviations and acronyms
This Recommendation uses the following abbreviations and acronyms:
CTP Connection Termination Point
EXER Exercise
FC Forwarding Construct
FS Forced Switch
MPLS Multi-Protocol Label Switching
MPLS-TP Multi-Protocol Label Switching-Transport profile
MS Manual Switch
MSRP MPLS-TP Shared Ring Protection
MT MPLS-TP
OAM Operations, Administration and Maintenance
- 9 -
SG15-TD583-R1/PLEN
SD Signal Degraded
SF Signal Fail
Sk Sink
SNC Subnetwork Connection
SNCP Subnetwork Connection Protection
SNC/S SNCP with Sublayer monitoring
So Source
TT Trail Termination
WTR Wait-to-Restore
5 Conventions
5.1 Information modelling conventions
See clause 5.1 of [ITU-T G.7711].
5.1.1 UML modelling conventions
See clause 5.1 of [ITU-T G.7711].
5.1.2 Model Artefact Lifecycle Stereotypes conventions
See clause 5.2 of [ITU-T G.7711].
5.1.3 Forwarding entity terminology conventions
See clause 5.3 of [ITU-T G.7711].
5.1.4 Conditional package conventions
See clause 5.4 of [ITU-T G.7711].
5.1.5 Pictorial diagram conventions
See clause 5.5 of [ITU-T G.7711].
5.2 Equipment function conventions
See clause 5.3 of [ITU-T G.8152].
5.3 Conventions defined in this Recommendation
See clause 5.3 of [ITU-T G.8152].
6 MPLS-TP Resilience Functions
This clause identifies the MPLS-TP Resilience functions that are modelled by the information
model and data models of this Recommendation.
6.1 Linear Protection Functions
MPLS-TP linear protection function is defined in [ITU-T G.8131]. For protection type
characteristic, it includes the following types:
- 10 -
SG15-TD583-R1/PLEN
Table 6.1-1 MPLS-TP Linear Protection type
Protection type Source
Unidirectional 1+1 SNC/S protection
switching
ITU-T G.8131
Bidirectional 1+1 SNC/S protection switching ITU-T G.8131
Bidirectional 1:1 SNC/S protection switching ITU-T G.8131
MPLS-TP trail protection ITU-T G.8131
6.2 Ring Protection Functions
MPLS-TP ring protection function is defined in [ITU-T G.8132]. For protection type characteristic,
it includes the following types:
Table 6.2-1 MPLS-TP Ring Protection type
Protection type Source
Wrapping ITU-T G.8132
Short wrapping ITU-T G.8132
Steering ITU-T G.8132
7 MPLS-TP Resilience Information Model
This clause contains the UML information model of the MPLS-TP Protection functions identified in
Clause 6. The information model is derived through pruning and refactoring the Recommendation
[ITU-T G.7711/Y.1702] core information model and Recommendation [ITU-T G.8152/Y.1375
(12/2016)] MPLS-TP base information model.
7.1 Required Object Classes and relations
7.1.1 Linear protection
[ITU-T G.8131] clause 6.1 describes the protection switching architecture for the MPLS-TP linear
protection group, including Unidirectional 1+1 SNC/S protection switching, bidirectional 1+1 SNC/S
protection switching, and bidirectional 1:1 SNC/S protection switching. All these architectures can
be modelled by using the same set of object classes, so we choose the Unidirectional 1+1 SNC/S
protection switching as an example to describe the MPLS-TP linear protection object classes. Annex
E of [ITU-T G.7711] has the generic resilience model applicable for the linear protection switching
schemes. The following Figure 7.1.1-1 and Table 7.1.1-1 show the mapping between the [ITU-T
G.8131] functions and the [ITU-T G.7711] and the [ITU-T G.8152] object classes for the MPLS-TP
linear protection.
- 11 -
SG15-TD583-R1/PLEN
Figure 7.1.1-1Mapping between G.8131 and G.7711 for MPLS-TP linear protection model
Table 7.1.1-1 Mapping between G.8131, G.8152 and G.7711 for MPLS-TP linear protection
G.8131 G.8152 G.7711
SNC protection
switching process
MT_SubnetworkConnectionProtectionGroup FcSwitch+CASC+ Spec
MT_C MT_CrossConnection FC+FcPort+Spec
MT_CP MT_ConnectionTerminationPoint LTP+Spec
The simplified resilience model for MPLS-TP linear protection can be expressed as in Figure 7.1.1-
2. The upper part of this figure is from Figure E.1-1 of [ITU-T G.7711], which shows the basic
resilience pattern.
As shown in Figure 7.1.1-2, object classes FcSwitch, ConfigurationAndSwitchControl (CASC), and
ControlParameters_Pac are used to support resilience.
The FcSwitch object class models the switched forwarding of traffic (traffic flow) between FcPorts and
is present where there is protection functionality in the FC. The FcSwitch represents and defines a
protection switch structure encapsulated in the FC and essentially performs one of the functions of the
protection group in a traditional information model.
The CASC represents the capability to control and coordinate switches, to add/delete/modify FCs and to
add/delete/modify LTPs/LPs so as to realize a protection scheme. The CASC can be composed of
CASCs allowing for expression of complex control structures, which is called encapsulation of the
CASC. There are several degrees of CASC: CASC encapsulated in an FcSwitch, CASC encapsulated
in an FC and CASC encapsulated in a CASC.
The ControlParameters_Pac defines a list of control parameters to apply to a switch.
- 12 -
SG15-TD583-R1/PLEN
Figure 7.1.1-2 Simplified resilience model for MPLS-TP Linear protection
The following text describes the MPLS-TP linear protection spec model.
In Figure 7.1.1-3 below, the following colour convention is used for the object classes. The orange
classes are from the [ITU-T G.7711] core model. The blue ones are defined in [ITU-T G.8152.2].
The pink ones are pruned & refactored from [ITU-T G.7711] but need to be further refactored. And
the yellow one is from [ITU-T G.8152].
In [ITU-T G.8152.2], the LinearProtection object class models the switched forwarding of traffic
(traffic flow) for linear protection, and it’s pruned and refactored from [ITU-T G.7711] and [ITU-T
G.8152]. And it is used to control and coordinate linear protection groups, to add/delete/modify FCs
and to add/delete/modify LTPs/LPs so as to realize a protection scheme. It also defines a list of control
parameters to apply to a switch.
The Actions interface class defines the operations for linear protection, and they are pruned and
refactored from [ITU-T G.8152].
For the pink ones, they need to be further refactored into UML artifacts which supposed to be re-
engineered from the IETF mpls-base & mpls-static RFC yang, which are yet to be finalized.
- 13 -
SG15-TD583-R1/PLEN
Figure 7.1.1-3 MPLS-TP linear protection spec model
7.1.2 Shared ring protection
[ITU-T G.8132] Figure 8-1 presents the function model of MSRP (see the upper part of Figure 7.1.2
1). [ITU-T G.7711] Annex E specifies the generic resilience information model. Figure 7.1.2 1 below
shows the mapping between the [ITU-T G.8132] MSRP functions and the [ITU-T G.7711]
information model artifacts for the MPLS-TP shared ring protection.
An MSRP ring tunnel is modelled as a server sub-layer for the MPLS-TP LSP sub-layer. Figure 8-1
of [ITU-T G.8132] shows the sub-layer functional model. The MSRP_C shows all the possible
working and protection connections that can be setup in the MSRP sub-layer.
- 14 -
SG15-TD583-R1/PLEN
Figure 7.1.2-1 Mapping between MSRP functions and information model artifacts
Table 7.1.2-1 Mapping between ITU-TG.8132, ITU-T G.8152 and ITU-T G.7711 for MSRP
ITU-T G.8132 ITU-T G.8152 ITU-T G.7711
MSRP switching process Not defined yet FcSwitch+CASC+ Spec
MSRP_C Not defined yet FC+ Spec
MSRP_CP Not defined yet FcPort +Spec
West ring port/East ring port MT_TrailTerminationPoint LTP +Spec
The simplified resilience model for MSRP can be expressed as in the Figure 7.1.2-2.
- 15 -
SG15-TD583-R1/PLEN
Figure 7.1.2-2 Simplified resilience model for MSRP
The descriptions for the FcSwitch, CASC, and ControlParameters_Pac object classes are the same in
Clause 7.1.1.
The following text describes the MSRP spec models. The same color convention of Figure 7.1.1-3
is used for Figure 7.1.2-3 below.
The Srp_FcSwitch object class models the switched forwarding of traffic (traffic flow), and it’s pruned
and refactored from [ITU-T G.7711] and [ITU-T G.8152]. The Srp_casc is used to control and
coordinate Fcswitches, to add/delete/modify FCs and to add/delete/modify LTPs/LPs so as to realize a
protection scheme. The ControlParameters_Pac defines a list of control parameters to apply to a
switch. The SRP_CascActions interface class defines the operations for shared ring protection.
For the pink object classes, they need to be further refactored into UML artifacts which supposed to
be re-engineered from the IETF mpls-base & mpls-static RFC yang, which are yet to be finalized.
- 16 -
SG15-TD583-R1/PLEN
Figure 7.1.2-3 MSRP spec model
Figure 7.1.2-4 shows the Fc instance model. It used to describe the relationship between ring tunnel
and LSP. MSRP ring tunnel is modelled as a server sub-layer for the MPLS-TP LSP sub-layer. As
shown in the figure, RingTunnelFc instance has lower level LSPFc instance.
Figure 7.1.2-4 Fc instance
Annex A describes the principles of MSRP, and it describes how to use MSRP resilience model to
represent the MSRP, and how to switch according to failures.
7.2 Required Attributes and Operations
7.2.1 Linear protection
This clause shows how the required [ITU-T G.7711] and [ITU-T G.8152] object classes are
pruned/refactored for linear protection.
In [ITU-T G.8152], the MPLS-TP linear protection is modelled by the MT_SNCP_Group object
class. The following tables verify the compatibility in attribute and operation level between [ITU-T
G.8152] and [ITU-T G.7711].
- 17 -
SG15-TD583-R1/PLEN
Table 7.2.1-1 Linear protection attributes mapping
Attributes in G.8152 Corresponding attributes in G.7711 Attributes for G.8152.2
1.
MT_SubNetworkConnectio
nProtectionGroup::Protectio
nType
It could be modelled as
ControlParameters_Pac specified
attribute.
Since this attribute indicates the
protection type of the SNCP Group.
LpFcSwitch::protection
Type. The datatype for
protectionType is
pruned and refactored
from [ITU-T G8152].
2.
MT_SubNetworkConnectio
nProtectionGroup::holdOffT
ime
This attribute already exists in the
ControlParameters_Pac.
LpFcSwitch::protection
Type. The datatype for
protectionType is
pruned and refactored
from [ITU-T G8152].
3.
MT_SubNetworkConnectio
nProtectionGroup::sncpGro
upState
It could be modelled as FcSwitch
specified attribute ProtectionState.
Since this attribute indicates the
protection state of the SNCP Group.
LpFcSwitch::protection
State, which is
Experimental.
4.
MT_SubNetworkConnectio
nProtectionGroup::isSdProt
ectionEnabled
It could be modelled as FcSwitch
specified attribute
isSdProtectionEnabled.
LpFcSwitch::sdProtecti
onEnabled, The
datatype for
protectionType is
pruned and refactored
from [ITU-T G8152].
Table 7.2.1-2 Linear protection operations mapping
Operations in G.8152 Corresponding attributes
in G.7711
Operations for G.8152.2
1.
MT_SubNetworkConnection
ProtectionGroup::lockoutProt
ection()
It could be considered by
setting FcSwitch as
lockout.
So it may use CASC
specified operations to
describe.
[ITU-T G.7711] clause
E.1.2.6: The FC switch
represents and defines a
protection switch structure
encapsulated in the FC and
essentially performs one of
the functions of the
protection group in a
traditional model. It may be
locked out (prevented from
switching), force switched
or manual switched.
Action Command, with
one input parameter
(commandType) defining
the type of command. For
this one, the command
type is
LOCKOUT_OF_PROTEC
TION.
2.
MT_SubNetworkConnection
ProtectionGroup::forceSwitch
()
It could be considered by
setting FcSwitch as
forceSwitch. CASC is the
control component for
Action Command, with
one input parameter
(commandType) defining
the type of command. For
- 18 -
SG15-TD583-R1/PLEN
FcSwitch.So it may use
CASC specified operations
to describe.
this one, the command
type is
FORCED_SWITCH.
3.
MT_SubNetworkConnection
ProtectionGroup::clearExtern
alCommandAndWTRstate()
It could be considered by
setting
FcSwitch::switchcontrol to
the clear.
May need to add “clear” to
FcSwitch::Switchcontrol.
So it may use CASC
specified operations to
describe.
ControlParameters_Pac
already has
WaitToRestoreTime
attributes
Action Command, with
one input parameter
(commandType) defining
the type of command. For
this one, the command
type is CLEAR.
4.
MT_SubNetworkConnection
ProtectionGroup:::manualSwi
tch()
It could be considered by
setting
FcSwitch::_SelectedFcPort
to the designated
switching port(the
protecting port or the
working port). So it may
use CASC specified
operations to describe the
command.
Switchcontrol already has
the value MANUAL
Action Command, with
one input parameter
(commandType) defining
the type of command. For
this one, the command
type
are
MANUAL_SWITCH_TO_
WORKING,
MANUAL_SWITCH_TO
_PROTECTION.
5.
MT_SubNetworkConnection
ProtectionGroup::exercise()
Need more discussion in
[ITU-T G.7711]
Action Command, with
one input parameter
(commandType) defining
the type of command. For
this one, the command
type is EXERCISE.
6.
MT_SubNetworkConnection
ProtectionGroup::localFreeze(
)
It could be considered by
setting
ConfigurationAndSwitchC
ontrol::isFroze as true.
Action Command, with
one input parameter
(commandType) defining
the type of command. For
this one, the command
type is FREEZE.
7.
MT_SubNetworkConnection
ProtectionGroup::clearLocalF
reeze()
It could be considered by
setting
ConfigurationAndSwitchC
ontrol::isFroze as false.
Action Command, with
one input parameter
(commandType) defining
the type of command. For
this one, the command
type is CLEAR_FREEZE.
- 19 -
SG15-TD583-R1/PLEN
In [ITU-T G.8152], it only describes these attributes and operations in table 7.2.1-1 and table 7.2.1-
2. But according to [ITU-T G.8131], it may also include the following attributes. See table 7.2.1-3.
Table 7.2.1-3 Linear protection attributes verification
Attributes in ITU-T G.8131
Corresponding attributes in ITU-T
G.7711
Attributes for
ITU-T G.8152.2
1 In clause 7, it has described the
selector chooses working or
protection connection. For the
port of the connection, it has
role.
It could be considered by FcPort.
And FcPort already has an
attribute “role” to describe the
role of the port.
FcPort::role,
specify the data
type of attribute
role, the specified
value include:
WORKING,
PROTECTING,
PROTECTED,
NA.
2 Clause 9 This already exists in the
ControlParameters_Pac.
LpFcSwitch::
reversionMode.
7.2.2 Shared ring protection
This clause shows how the required [ITU-T G.7711] and [ITU-T G.8152] object classes are
pruned/refactored for MSRP.
In [ITU-T G.8152], there is no object class defined for MSRP. The following tables provides the
mapping between the [ITU-T G.8132] MSRP characteristics and the information artifacts according
to the MSRP model in clause 7.1.2.
Table 7.2.2-1 MSRP attributes mapping
Attributes in [ITU-T G.8132] Corresponding attributes
in [ITU-T G.7711]
Attributes for [ITU-T
G.8152.2]
5.
Three types of ring protection
mechanisms are specified:
wrapping, short wrapping and
steering
This attribute already
exists in the
ControlParameters_Pac::p
rottype. But the values of
prottype are not defined.
So it should specify the
it’s values.
ControlParameters_Pac::p
rottype.
As CIM doesn’t descirbe
the data type values for
prottype, the values are
specified from [ITU-T
G8132].
6.
MSRP supports only the bi-
directional protection
switching type
It could be modelled as
FcSwitch Specified
attribute Switchingtype.
FcSwitch::Switchingtype,
this attribute is specified
from [ITU-TG.8132].
7. revertive protection operation
type
It already exists in
ControlParameters_Pac::r
eversionMode
ControlParameters_Pac::r
eversionMode
8. ring protection switch state It could be modelled as
FcSwitch Specified
FcSwitch::RingProtection
State, this attribute is
- 20 -
SG15-TD583-R1/PLEN
attribute
RingProtectionState.
specified from [ITU-T
G.8132].
9. Wait-to-Restore
It already exists in
ControlParameters_Pac::w
aitToRevertTime.
ControlParameters_Pac::w
aitToRevertTime
Table 7.2.2-2 MSRP operations mapping
Operations in [ITU-T
G.8132]
Corresponding attributes in
[ITU-T G.7711]
Operations for [ITU-T
G.8152.2]
1.
Lockout of
Protection(LP),
Lockout of
Working(LW)
It could be considered by
setting FcSwitch as lockout.
CASC is the control
component for FcSwitch. So
it may use CASC specified
operations to represent.
CASC specified
operations::lockout() ,
specified parameter
lockOutType will describe
the type: lockout to
protection or lockout to
working.
2.
Forced Switch (FS) It could be considered by
setting FcSwitch as
forceSwitch. CASC is the
control component for
FcSwitch. So it may use
CASC specified operations
to describe.
CASC specified
operations::forceSwitch()
3.
Manual Switch (MS) It could be considered by
setting FcSwitch as manual
switch. CASC is the control
component for FcSwitch. So
it may use CASC specified
operations to describe.
CASC specified
operations::manualSwitch()
4.
Exercise (EXER) It could be considered by
setting FcSwitch as manual
switch. CASC is the control
component for FcSwitch. So
it may use CASC specified
operations to describe.
CASC specified
operations::exercise()
5.
Clear: clears the
administrative
command and WTR
timer
It could be considered by
setting FcSwitch as clear.
CASC is the control
component for FcSwitch. So
it may use CASC specified
operations to describe.
CASC specified
operations::clearAdministrat
orCommandAndWTRstate()
6.
Automatically
Command
It could be considered by
setting FcSwitch as
automatically.
CASC specified
operations::automatic()
- 21 -
SG15-TD583-R1/PLEN
7.3 UML model files
7.3.1 Linear protection
This sub-clause contains the linear protection UML model files developed using the Papyrus open-
source modelling tool.
itut-mpls-tp-linear-protection.zip
This zip contains the ITU-T G.8152.2 linear protection model files (i.e., the .project, .di, .notation
and .uml files) and the profiles.
The linear protection model uses the following modelling tool and profiles
- Eclipse 4.9 (i.e. version 2018.09)
- Papyrus 4.1.0,
- OpenModel_Profile 0.2.17,
- OpenInterfaceModel_Profile 0.0.10,
- ProfileLifecycle_Profile 0.0.4.
7.3.2 Ring protection
This sub-clause contains the shared ring protection UML model files developed using the Papyrus
open-source modelling tool. Note that it needs further discussion, so the shared ring protection
UML is preliminary.
itut-mpls-tp-shared-ring-protection.zip
8 MPLS-TP Resilience Data Models
This clause contains the interface-protocol-specific data models of the MPLS-TP resilience
functions identified in Clause 6. These data models are translated from the interface-protocol-
neutral UML information specified in Clause 7.
8.1 YANG Data Model
This clause contains the YANG Data Model.
The YANG data models defined in this Recommendation uses the YANG 1.1 language defined in
[IETF RFC 7950]. The YANG data types defined in [IETF RFC 6991] is used for the YANG data
types representation. The tree format defined in [IETF RFC 8340] is used for the YANG data model
tree representation.
The YANG data models defined in this Recommendation conforms to Network Management
Datastore Architecture in [IETF RFC 8342].
8.1.1 Linear protection
This clause contains the G.8152.2 linear protection YANG data model. The G.8152.2 linear
protection YANG model is translated from the UML information provided in Clause 7.3.1. The
translation is done with the assistance of the Open Source translation tooling xmi2yang, which is
developed according to the [b-ONF TR-531] Mapping Guidelines.
1) The yang generated by the xmi2yang mapping tool directly from the uml:
- 22 -
SG15-TD583-R1/PLEN
itut_mpls-tp_linear_protection_2020-09-16_yang_gen.zip
2) As the time of publication of this Recommendation, the xmi2yang mapping tool is still
working in progress. Therefore manual modifications on the tool-generated yang are
necessary. Embedded below is the yang with such manual modifications.
itut_mpls-tp_linear_protection_2020-09-16_yang.zip
The YANG tree is as below:
itut_mpls-tp_linear_protection_2020-09-16_yang_tree.zip
8.1.2 Ring protection
Since the base UML model of shared ring protection is still preliminary, the yang model is also
preliminary. It needs further discussion. The G.8152.2 shared ring protection YANG model is
translated from the UML information provided in Clause 7.3.2. The translation is done with the
assistance of the Open Source translation tooling xmi2yang, which is developed according to the [b-
ONF TR-531] Mapping Guidelines.
itut-mpls-tp-shared-ring-protection.uml@2020-09-16_yang_gen.zip
8.2 Other Data Model
None.
- 23 -
SG15-TD583-R1/PLEN
Annex A
MSRP information model
(This annex forms an integral part of this Recommendation.)
The focus of this annex is the modelling of shared ring protection. It:
– introduces the MSRP resilience principle
– shows how the model deals with failures
The MSRP architecture is specified in ITU-T Recommendation [ITU-T G.8132]. This section gives
an overview of the architecture to be used to describe the MSRP management information model.
As shown in figure A-1 below, the new logical layer consists of ring tunnels that provide a server
layer for the LSPs traversing the ring. The notation used for a ring tunnel is: R<d><p>_<X> where
<d> = c (clockwise) or a (anticlockwise), <p> = W (working) or P (protecting), and <X> =the node
name.
Once a ring tunnel is established, the forwarding and protection switching of the ring are all
performed at the ring tunnel level. MPLS-TP section layer OAM is needed for continuity check,
remote defect indication and fault detection, and protection operations are controlled by the RPS
protocol as described in IETF RFC 8227. A port can carry multiple ring tunnels, and a ring tunnel
can carry multiple LSPs.
Figure A-1 The Logic Layers of The Ring
The Ring tunnels are established based on the egress nodes. The egress node is the node where
traffic leaves the ring. LSPs that have the same egress node on the ring and travel along the ring in
the same direction (clockwise or anticlockwise) share the same ring tunnels. For each egress node
four ring tunnels are established:
(1) one clockwise working ring tunnel, which is protected by the anticlockwise protection ring
tunnel.
(2) one anticlockwise protection ring tunnel.
- 24 -
SG15-TD583-R1/PLEN
(3) one anticlockwise working ring tunnel, which is protected by the clockwise protection ring
tunnel.
(4) one clockwise protection ring tunnel.
The principle of the protection tunnels is determined by the selected protection mechanism
(wrapping, short-wrapping, steering). This will be detailed in the following sections.
As shown in Figure A-2, LSP1, LSP2, and LSP3 enter the ring from Node A, Node E, and Node B
respectively, and all leave the ring at Node D. To protect these LSPs that traverse the ring, a
clockwise working ring tunnel (RcW_D) via E->F->A->B->C->D and its anticlockwise
protection ring tunnel (RaP_D) via D->C->B->A->F->E->D are established. Also, an anticlockwise
working ring tunnel (RaW_D) via C->B->A->F->E->D and its clockwise protection ring tunnel
(RcP_D) via D->E->F->A->B->C->D are established. For simplicity, Figure A-2 only shows
RcW_D and RaP_D. A similar provisioning should be applied for any other node on the ring. In
summary, for each node in Figure A-2, when acting as an egress node, the ring tunnels are created
as follows:
(1) To Node A: RcW_A, RaW_A, RcP_A, RaP_A
(2) To Node B: RcW_B, RaW_B, RcP_B, RaP_B
(3) To Node C: RcW_C, RaW_C, RcP_C, RaP_C
(4) To Node D: RcW_D, RaW_D, RcP_D, RaP_D
(5) To Node E: RcW_E, RaW_E, RcP_E, RaP_E
(6) To Node F: RcW_F, RaW_F, RcP_F, RaP_F
F A
B
CD
E
LSP1
LSP1
LSP3LSP2
LSP2LSP3 RaP_D
RcW_D
Figure A-2 Ring tunnels in MSRP
Following sections specifies the ring protection mechanisms in detail. In general, the description
uses the clockwise working ring tunnel and the corresponding anticlockwise protection ring tunnel
as an example, but the mechanism is applicable in the same way to the anticlockwise working and
clockwise protection ring tunnels.
- 25 -
SG15-TD583-R1/PLEN
A.1 wrapping
Figure A.3 shows a view a basic network. A signal is passing from port3 node A to port 3 node D.
LSP1 is through the path A-B-C-D.
F A
B
CD
E
3
21
1
2
21
12
2
1
12
3
LSP1
LSP1
Figure A-3 basic network
When a link failure between node B and node C occurs, see the following Figure A-4. Node B
switches the clockwise working ring tunnel to the anticlockwise protection ring tunnel, and sends a
status message to the node C along the ring away from the link failure, notifying node C to switch
from the working tunnel to the corresponding protection tunnel. Then signal then will follow the
path A-B-A-F-E-D-C-D.
- 26 -
SG15-TD583-R1/PLEN
Figure A-4 Wrapping for link failure
The following figures show the object classes (LTP and FC, FcSwitch, CASC) configurations for
nodes in the ring under normal and failure condition.
FCCASC
W
P
FcSwitch
LTP LTP1 2
Figure A-5 Wrapping: node B and node C (no failure in ring)
Figure A-5 above shows the configurations of Node B and Node C with the switches set to normal
position. There is an actual FC allowing signal to flow between the Working ring tunnel.
F A
B
CD
E
3
21
1
2
21
12
2
1
12
3
LSP1
LSP1
- 27 -
SG15-TD583-R1/PLEN
FCCASC
W
FcSwitch
LTP LTP1 2
W
P
LTP
3
Figure A-6 Wrapping: node D (no failure in ring)
Figure A-6 above shows the configurations of Node D with the switches set to normal position.
There is an actual signal to flow between port1 to port3 on the working ring tunnel.
Note that Node A has the same configuration, except that port 2 is used for normal signal flow and
the protection faces port 1 not port2.
FCCASC
W
P
FcSwitch
LTP LTP1 2
W
P
Figure A-7 Wrapping: node B with failure on link between node B and node C
- 28 -
SG15-TD583-R1/PLEN
Figure A-7 above shows the configurations of Node B with a failure on link between Node B and
Node C, such that the switches on the port1 have been set to the protection ring tunnel. The FC
allows signal to flow between the working and protection on port1, such that the signal is wrapped
back to port1.
FCCASC
W
P
FcSwitch
LTP LTP1 2
Figure A-8 Wrapping: node C with failure on link between node B and node C
Figure A-8 above shows the configurations of node C with a failure on link between node B and
node C. It is the same to node B, except that in node C the switching position is on port 2.
FCCASC
W
P
FcSwitch
LTP LTP1 2
P P
- 29 -
SG15-TD583-R1/PLEN
Figure A-9 Wrapping: node E and node F with failure on link between node B and node C
Figure A-9 above shows the configurations on node E and node F for the failure on link between
node B and node C. There is an actual Fc allows signal to flow between the protection ring tunnel
on port1 and port2 due to the wrap in node B shown in the previous figure.
Node A and node D do not need to switch to the protection ring runnel as node B and node C
perform the protection function in this case. In general, for the wrapping scheme, the Nodes on
either side of the failure perform the protection function.
A.3 Steering
With the steering ring scheme, the ingress node performs switching from working to the protection
ring, and at the egress node, the traffic leaves from the ring from the protection ring tunnel.
Figure A-15 shows a view of the basic network. This figure is the same to A-3 A signal is passing
from port3 node A to port 3 node D. LSP1 is through the path A-B-C-D.
F A
B
CD
E
3
21
1
2
21
12
2
1
12
3
LSP1
LSP1
Figure A-15 basic network
When a link failure between node B and node C occurs, as shown in the following Figure A-16,
node A switches the signal from the clockwise working ring tunnel to the anticlockwise protection
ring tunnel, and leaving at node D on the protection ring tunnel. The signal then will follow the path
A-F-E-D.
- 30 -
SG15-TD583-R1/PLEN
F A
B
CD
E
3
21
1
2
21
12
2
1
12
3
LSP1
LSP1
Figure A-16 Steering for link failure
The following figures show the LTP and FC configurations for nodes in the ring under normal and
failure condition.
For the normal condition, the switches in node B, node C, node D and node A are the same to the
wrapping situation as shown in Figure A-5 and Figure A-6.
When there is a failure on link between Node B and Node C, the ring nodes may work as shown in
the following figures.
- 31 -
SG15-TD583-R1/PLEN
FCCASC
W
P
FcSwitch
LTP LTP2 3
P P
Figure A-17 Steering: node D with failure on link between node B and node C
Figure A-17 above shows the configurations of Node D with a failure on link between Node B and
Node C, there is an actual FC that allows signal to flow between the protection path on port2 and
port3.
FCCASC
W
P
FcSwitch
LTP LTP1 2
W
P
LTP
3
Figure A-18 Steering: node A with failure on link between node B and node C
Figure A-18 above shows the configurations of Node A with a failure on link between Node B and
Node C, such that the signal is switched to flow between protection port1 and working port3.
- 32 -
SG15-TD583-R1/PLEN
FCCASC
W
P
FcSwitch
LTP LTP1 2
P P
Figure A-19 Steering: node E and node F with failure on link between node B and node C
Figure A-19above shows the configurations on node E and node F for the failure on link between
node B and node C. There is an actual FC that allows signal to flow between the protection path on
port1 and port2 due to the switching in node A shown in the previous figure.
Node B and node C are not involved in the switching.
- 33 -
SG15-TD583-R1/PLEN
A.2 short-wrapping
With the wrapping ring scheme, protection switching is executed at both nodes adjacent to the
failure. But with the short-wrapping ring scheme, protection switching is executed only at the node
upstream to the failure. And the packet leaves the protection ring at the egress end. Figure A-10
shows a view of a basic network. This figure is the same to A-3. A signal is passing from port3
node A to port 3 node D. LSP1 is through the path A-B-C-D.
F A
B
CD
E
3
21
1
2
21
12
2
1
12
3
LSP1
LSP1
Figure A-10 basic network
When a link failure between node B and node C occurs, see the following Figure A-11. Node B
switches the clockwise working ring tunnel to the anticlockwise protection ring tunnel, and leaves
at node D on the protection ring tunnel. The signal then will follow the path A-B-A-F-E-D.
- 34 -
SG15-TD583-R1/PLEN
F A
B
CD
E
3
21
1
2
21
12
2
1
12
3
LSP1
LSP1
Figure A-11 short-wrapping for link failure
The following figures show the LTP and FC configurations for nodes in the ring under normal and
failure condition.
For the normal condition, the switches in nodes B, C, D and A are the same to the wrapping
situation as shown in Figure A-5 and Figure A-6.
When there is a failure on the link between Node B and Node C, the nodes will work as shown in
the following figures.
- 35 -
SG15-TD583-R1/PLEN
FCCASC
W
P
FcSwitch
LTP LTP1 2
W
P
Figure A-12Wrapping: node B with failure on link between node B and node C
Figure A-12 above shows the configurations of Node B with a failure on the link between Node B
and Node C, such that the switches on the port1 have been set to the protection path. The FC allows
signal to flow between the working and protection on port1, such that the signal is wrapped back to
port1. For this node, it is the same to Figure A-7 wrapping scheme.
FCCASC
W
P
FcSwitch
LTP LTP1 2
P P
Figure A-13 short-wrapping: node E and node F with failure on link between node B and node C
- 36 -
SG15-TD583-R1/PLEN
Figure A-13 above shows the configurations on node E and node F for the failure on the link
between node B and node C. There is an actual FC that allows signal to flow between the protection
path on port1 and port2 due to the wrapping in node B as shown in the previous figure.
FCCASC
W
P
FcSwitch
LTP LTP2 3
P P
Figure A-14 short-wrapping: node D with failure on the link between node B and node C
Figure A-14 above shows the configurations on node D for the failure on the link between node B
and node C. There is an actual FC that allows signal to flow between the protection path on port2
and port3 due to the wrap in node B as shown in the previous figure.
Node A does not need to switch as node B performs the protection function in this case. Node C
does not include in this scheme because the signal leaves through node D. In general, for the short-
wrapping scheme, only the node on the upstream side of the failure performs the protection
function. However, the two directions of a protected bidirectional LSP are no longer co-routed
under the protection-switching conditions.
- 37 -
SG15-TD583-R1/PLEN
Appendix I
Linear protection examples
(This appendix does not form an integral part of this Recommendation.)
I.1 1+1/1:1 cases
This clause deals with MPLS-TP 1+1/1:1 protection group and shows how they can be represented.
PartitionFcHasLowerLevelFcs
FigureI.1-1 simple example of Linear 1+1/1:1(from [ITU-T G.7711] Figure XIV.1-1)
Figure I.1-1shows a simple example of a 1+1/1:1 case in a basic network with three NEs. Of course this
can be generalized to more NEs. The end-end FC is partitioned into subordinate (via
FcHasLowerLevelFcs). MPLS-TP SNC/S protection and trail protection all can be represented by this
common example.
CASC
CASC
1+1
1+1CASC encapsulated in FC
i
i
1+1CASC encapsulated in FCSwitch
Figure I.1-2 detail of a nodal view of 1+1 switches
- 38 -
SG15-TD583-R1/PLEN
Figure I.1-2 above shows a nodal view of 1+1 switches. It describes the
ConfiguraionAndSwitchControllers (CASC) encapsulated in the Fc (the upper part of the figure) and
ConfiguraionAndSwitchControllers encapsulated in the FcSwitch (the below part of the figure). The
encapsulation type depends upon the scope of control of the CASC. The encapsulation is via
FcSwitchCoordinatedByInternalControl when in the FcSwitch and
FcSwitchesInFcCoordinatedBySwitchCoordinator when in the FC.
i
o
CASC
i
o
biCASC 1:1
CASC encapsulated in FCSwitch
1:1 CASC encapsulated in FC
Figure I.1-3 detail of a nodal view of 1:1 switches
Figure I.1-3 above shows a nodal view of 1:1 switches. It describes the
ConfiguraionAndSwitchControllers (CASC) encapsulated in the Fc (the upper part of the figure) and
ConfiguraionAndSwitchControllers encapsulated in the FcSwitch (the below part of the figure).
i
o
CASC
o
i
CASC
C&SC
Common parameters only
FigureI.1-4 Showing a high-level abstract controller in a 1:1 case
- 39 -
SG15-TD583-R1/PLEN
Figure I.1-4 shows a case of 1:1 independent switching, in which the two directions of traffic are
switched independently. The figure assumes that the CASCs in the FCs at each end are distributed. It
highlights a high-level CASC which can be used to collect common parameters that should be set to the
same value at both ends. In this case, the high level CASC governs the lower level CASC.
- 40 -
SG15-TD583-R1/PLEN
Bibliography
[b-ONF TR-531] ONF TR-531_UML-YANG Mapping Guidelines
(https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-
content/uploads/2014/10/TR-531_UML-
YANG_Mapping_Guidelines_v1.0.pdf)
[b- IETF-mpls-base] YANG Data Model for MPLS Base (work in progress) (March 2020),
(https://tools.ietf.org/html/draft-ietf-mpls-base-yang-14)
[b-IETF-mpls-static] YANG Data Model for MPLS Static LSPs (work in progress) (April 2020),
(https://tools.ietf.org/html/draft-ietf-mpls-static-yang-11)
_____________________________
top related