ETSI GS mWT 024 V1.2.1 (2023-04)

millimetre Wave Transmission (mWT); Definition of a Wireless Transport Profile for Standard SDN Northbound Interfaces

RGS/mWT-0024v1_2_1

General Information

• Status: Not Published
• Technical Committee: mWT - millimetre Wave Transmission
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 19-Apr-2023
• Completion Date: 11-Apr-2023

Standards Content (Sample)

GROUP SPECIFICATION
millimetre Wave Transmission (mWT);
Definition of a Wireless Transport Profile for
Standard SDN Northbound Interfaces
Disclaimer
The present document has been produced and approved by the millimetre Wave Transmission (mWT) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS mWT 024 V1.2.1 (2023-04)

Reference
RGS/mWT-0024V1_2_1
Keywords
microwave, millimetre wave, mWT, NBI, profile,
SDN, transmission, wireless
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2023.
All rights reserved.
ETSI
3 ETSI GS mWT 024 V1.2.1 (2023-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Scope of the Profile . 10
4.1 Network Architecture . 10
4.2 Use Cases . 10
4.2.1 Microwave and Ethernet Topology Discovery . 10
4.2.1.1 Overview . 10
4.2.1.2 Microwave Topology . 11
4.2.1.3 Ethernet TE Topology . 12
4.2.1.3.1 Introduction . 12
4.2.1.3.2 External Ethernet Links and Inter-Domain Connectivity . 12
4.2.2 Ethernet Service Configuration. 13
4.2.2.1 Ethernet Services . 13
4.2.2.2 Bandwidth Profiles . 14
4.2.2.2.1 BWPs in the Ethernet TE Topology . 14
4.2.2.2.2 BWPs in the Service Model . 14
4.2.2.2.3 Full Example of Service, Ethernet TE Topology and MW Topology . 15
4.3 Abstraction Levels . 16
4.3.1 Introduction. 16
4.3.2 AL1: Abstraction Level 1 - "Black-box" . 16
4.3.2.1 Definition . 16
4.3.2.2 AL1 Representation of Multi-Region Domains . 16
4.3.2.2.1 Full connectivity, VLAN Isolation . 16
4.3.2.2.2 Partial connectivity, VLAN Isolation . 16
4.3.2.2.3 VLAN Transparency . 17
4.3.3 AL2: Abstraction Level 2 - "Partially Transparent" . 17
4.3.3.1 Definition . 17
4.3.3.2 AL2 Representation of Multi-Region Domains . 17
4.3.3.2.1 Partial connectivity, VLAN Isolation . 17
4.3.3.2.2 Partial connectivity, VLAN Transparency . 18
4.3.3.2.3 Considerations about the Representation of Multi-Region Domains . 18
5 MPI interface . 19
5.1 Reference SDN Architecture . 19
5.2 Specifications at the MPI . 19
5.2.1 RESTCONF Protocol . 19
5.2.2 YANG data models . 19
5.2.2.1 YANG Version . 19
5.2.2.2 Common YANG data models . 19
5.2.2.3 YANG Data Models at the Microwave MPI . 20
5.2.2.4 Hierarchical relationship among YANG data models . 20
5.3 Service Assurance and Exception handling . 21
5.3.1 Service Assurance . 21
5.3.2 Exception Handling . 21
ETSI
4 ETSI GS mWT 024 V1.2.1 (2023-04)
Annex A (normative): Detailed list of Models, Modules and Attributes . 22
A.1 Data modules . 22
A.2 Model trees . 22
A.2.1 General Considerations . 22
A.2.2 Microwave Topology (draft-ietf-ccamp-mw-topo-yang-02) . 22
A.2.3 Ethernet TE topology (draft-ietf-ccamp-eth-client-te-topo-yang-01) . 24
A.2.4 Ethernet service (draft-ietf-ccamp-client-signal-yang-05) . 27
Annex B (normative): Use of LLDP for automatic external Ethernet link discovery . 30
B.1 Introduction . 30
B.2 Algorithm description. 30
B.3 Example Calculation of the inter-domain-plug-id Value . 31
B.3.1 Domain A LLDP Packet TLV Values . 31
B.3.2 Domain B LLDP Packet TLV Values . 32
B.3.3 Sorting and Concatenation . 32
Annex C (informative): Examples . 34
C.1 Physical Network . 34
C.2 Microwave and Ethernet TE Topologies . 34
C.2.1 Topology Model of the Physical Network . 34
C.2.2 Types of Ethernet LTPs . 35
C.2.2.1 Edge Ethernet LTP, C-VLAN-Bridge Capable Network. 35
C.2.2.2 Edge Ethernet LTP, Provider Bridge Capable Network . 36
C.2.2.3 Edge Ethernet LTP, Customer Edge Port . 36
C.2.2.4 Summary of Edge Ethernet LTP Types . 37
C.3 Examples of Service Types . 37
C.3.1 Relationship among Service Types and LTP Types . 37
C.3.2 Selected Examples of Supported Service Configurations . 39
Annex D (informative): AL1 Representation of Multi-Region Domains with VLAN
Transparency . 49
D.1 Introduction . 49
D.2 AL1, Full connectivity, VLAN Transparency . 49
D.3 AL1, Partial Connectivity, VLAN Transparency . 50
Annex E (informative): Bibliography . 51
History . 52

ETSI
5 ETSI GS mWT 024 V1.2.1 (2023-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) millimetre Wave
Transmission (mWT).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
The rapid evolution of telecommunications networks towards ever higher complexity and agility requires increasing
levels of automation in network and service management. The range of technologies and solutions grouped under the
collective name of SDN is a fundamental component of such automation.
Automation through SDN applies to every segment and layer of the telecommunications networks, including the
wireless transmission technology.
SDN adoption is still in the early phases, and there exists a multitude of standards from several SDOs, that are in
principle applicable to wireless transmission. Often these standards are specified in a way covering a very wide
spectrum of applications and transmission technologies. This creates potentially a very large number of
standard-compliant but non-interoperable implementations of SDN even for a single technology or application.
ETSI
6 ETSI GS mWT 024 V1.2.1 (2023-04)
The purpose of the present document is to describe a parsimonious subset ("Profile") of the relevant available standards,
and a set of recommendations for best practices, suitable to support the functionalities described in the wireless
transmission Use Cases in clause 4.2.

ETSI
7 ETSI GS mWT 024 V1.2.1 (2023-04)
1 Scope
The present document defines a Profile for standard SDN northbound interfaces in Wireless transmission networks.
Specifically, the NBI refers to the MPI interface as defined in IETF RFC 8453 [12].
The term Profile is used for the present document because it identifies the selection of standard Models and the
selection Attributes therein from the IETF library as specified in Annex A, but does not define any additional standard
models or attributes.
This Profile applies exclusively to a single MW or mmW domain. A domain may be composed by one or more
homogeneous regions, all managed by a single PNC.
In addition, Annex B contains the description of the usage of the LLDP protocol [17] for the automatic detection of
inter-domain Ethernet access links, and an algorithm to calculate the inter-domain-plug-id [16] value.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] IETF draft-ietf-ccamp-mw-topo-yang-02: "A YANG Data Model for Microwave Topology".
[2] IETF draft-ietf-ccamp-eth-client-te-topo-yang-01: "A YANG Data Model for Ethernet TE
Topology".
[3] IETF draft-ietf-ccamp-client-signal-yang-06: "A YANG Data Model for Transport Network Client
Signals".
[4] IETF draft-ietf-teas-yang-te-28: "A YANG Data Model for Traffic Engineering Tunnels, Label
Switched Paths and Interfaces".
[5] IETF RFC 6991: "Common YANG Data Types".
[6] IETF RFC 7950: "The YANG 1.1 Data Modeling Language".
[7] IETF RFC 7951: "JSON Encoding of Data Modeled with YANG".
[8] IETF RFC 8040: "RESTCONF Protocol".
[9] IETF RFC 8294: "Common YANG Data Types for the Routing Area".
[10] IETF RFC 8342: "Network Management Datastore Architecture (NMDA)".
[11] IETF RFC 8345: "A YANG Data Model for Network Topologies".
[12] IETF RFC 8453: "Framework for Abstraction and Control of TE Networks (ACTN)".
[13] IETF RFC 8525: "YANG Library".
[14] IETF RFC 8527: "RESTCONF Extensions to Support the Network Management Datastore
Architecture".
ETSI
8 ETSI GS mWT 024 V1.2.1 (2023-04)
[15] IETF RFC 8528: "YANG Schema Mount".
[16] IETF RFC 8795: "YANG Data Model for Traffic Engineering (TE) Topologies".
[17] IEEE 802.1AB™: "IEEE Standard for Local and metropolitan area networks - Station and Media
Access Control Connectivity Discovery".
[18] IEEE 802.1Q™-2018: "IEEE Standard for Local and Metropolitan Area Networks-Bridges and
Bridged Networks".
[19] IETF RFC 8776: "Common YANG Data Types for Traffic Engineering".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] MEF 4 Technical Specification: "Metro Ethernet Network Architecture Framework - Part 1:
Generic Framework".
[i.2] MEF 6.3 Technical Specification: "Subscriber Ethernet Services Definitions".
[i.3] MEF 10.3 Technical Specification: "Ethernet Services Attributes Phase 3".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
access ethernet link: external ethernet link that is connected to a final user (e.g. NodeB), usually of UNI-C type
NOTE: See MEF 4 [i.1].
domain: (by default) entirety of the domain controlled by the PNC implementing the MPI under consideration
edge ethernet LTP: ethernet LTP that is connected to an external ethernet link
ethernet connection: bi-directional construct comprising two uni-directional ethernet links connecting a couple of
ethernet LTPs
external ethernet link: ethernet link that has one termination inside and the other one outside of the domain managed
by the PNC
NOTE 1: It can be further classified as an inter-domain ethernet link, or an access ethernet link.
NOTE 2: The PNC has no information about the nature of such links, in particular if these are a UNI or an NNI and
whether they are connected to a final client (e.g. NodeB) or to another transport domain (e.g. router,
DWDM, etc.).
full ethernet connectivity: complete reachability of all ethernet edge LTPs with one another
homogeneous region: subset of microwave network elements within a domain, that have full ethernet connectivity, and
provide the same VLAN functionality on all edge LTPs
ETSI
9 ETSI GS mWT 024 V1.2.1 (2023-04)
inter-domain ethernet link: external ethernet link that is connected to a transport domain (e.g. router, DWDM, etc.) or
to another MW domain, usually of NNI type
NOTE: See MEF 4 [i.1].
internal ethernet link: ethernet link connecting Ethernet LTPs belonging the TE Ethernet topology of the domain
managed by the PNC
multi-region domain: microwave domain that is composed internally by more than one homogeneous region, lacking
full ethernet connectivity amongst them
partial ethernet connectivity: incomplete reachability of some ethernet edge LTPs with one another
VLAN isolation: capability of a homogeneous region to isolate the internal VLAN addressing space for path selection
from any external one
NOTE: The MDSC does not need to have any information about the VLAN operation capabilities, addressing
space, available ranges inside a region that provides VLAN isolation, and does not need to coordinate the
external VLAN ID addressing space with the internal domain one.
VLAN transparency: lack of VLAN isolation capability by a homogeneous region
NOTE 1: The MDSC may or may not have visibility of these information; in any case its ability to configure any of
those parameters is regulated according to the chosen Abstraction Level (see clause 4.3).
NOTE 2: If MDSC does not take into account the VLAN ID usage inside the domain, and coordinate it with the
external VLAN ID address space, the PNC may not be able to instantiate a requested service, resulting in
a trial and error process by the MDSC.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACTN Abstraction and Control of TE Networks
AL Abstraction Level
AN Abstract Node
B2B Business to Business
BWP Bandwidth Profile
CBS Committed Burst Size
CIR Committed Information Rate
CLTP Carrier Link Termination Point
CM Connectivity Matrix
C-VID C-VLAN ID
C-VLAN Client-Side VLAN
DWDM Dense Wavelength Division Multiplexing
E2E End to End
EBS Excess Burst Size
eeLTP Ethernet edge LTP
EIR Excess Information Rate
eLTP Ethernet LTP
ETH Ethernet
GE Gigabit Ethernet
ID Identity
JSON JavaScript Object Notation
LLDP Link Layer Discovery Protocol
LTP Link Termination Point
MDSC Multi-Domain Service Coordinator
mmW Millimetre Wave
ETSI
10 ETSI GS mWT 024 V1.2.1 (2023-04)
MPI MDSC-PNC Interface
MW Microwave
NBI Northbound Interface
NE Network Element
NMDA Network Management Datastore Architecture
NNI Network Network Interface
PNC Provisioning Network Controller
RFC Request for Comments
RLTP Radio Link Termination Point
ro read-only
rw read-write
SDN Software Defined Networking
SDO Standard Defining Organization
S-VLAN Service-Side VLAN
TE Traffic Engineering
TLV Type-Length-Value
UNI User Network Interface
UNI-C User Network Interface - Customer Edge
VID VLAN ID
VLAN Virtual Local Area Network
WBH Wireless Backhaul
WTN Wireless Transmission Network
4 Scope of the Profile
4.1 Network Architecture
This Profile applies to a single domain of MW and mmW devices. The interactions with other domains are covered by
the selection of the attributes necessary to identify the Ethernet access links from [2], and the Ethernet service
characteristics from [3].
The Profile applies to physical WTN topologies that do not allow for multiple paths to connect two eeLTPs. Only
wireless links of point-to-point type are considered, i.e. radio links comprising two radio NEs.
4.2 Use Cases
4.2.1 Microwave and Ethernet Topology Discovery
4.2.1.1 Overview
The network discovery Use Case is the basic functionality needed for network and service management automation, in
that it shall provide the inventory of the microwave topology, the Ethernet topology and the Ethernet service
information.
Figure 4.2.1.1.1 shows the relationships between the Microwave and the ethernet topologies for a microwave link with
two bonded radio carriers.
ETSI
11 ETSI GS mWT 024 V1.2.1 (2023-04)
Ethernet TE Topology
Towards other domains Towards domain’s interior
External
Ethernet Link 1 Ethernet Link 3
Ethernet Link 5
1 1 2
NE1 NE2
External Ethernet Link 4
Ethernet Link 6
Ethernet Link 2
Edge eth LTP Internal eth LTP Internal eth LTPs
node-id node-id
underlay
Microwave Topology
MW RLTP
Microwave Link 1
1 6
Microwave Link 2
Microwave Carrier 1
2 Microwave Carrier 2 7
NE1 NE2
Microwave Carrier 3
3 Microwave Carrier 4 8
MW CLTPs
NOTE 1: The external ethernet links are shown for clarity only, the PNC needs to keep information only about the
eeLTPs.
NOTE 2: LTPs of a given node are part of the same list and have different names (ltp-id), which are local to that
node. There is no relation among the name spaces of LTPs across different nodes.

Figure 4.2.1.1.1: Microwave and Ethernet Topologies
4.2.1.2 Microwave Topology
The microwave topology provides identification of the physical network by means of the microwave nodes, LTPs and
radio links.
The following clarifications shall apply:
1) The two nodes are connected by two microwave radio links (one for each direction), each of which can consist
of more than one radio carrier, attached to the respective radio LTPs. Microwave links and radio carriers are
modelled as separate link entities, microwave-radio-link and microwave-carrier, and each of them is
attached to specific LTP (microwave-rltp and microwave-cltp). It is assumed that the multiple carriers
associated to the microwave link carry the data traffic associated to the Ethernet services as a bundle, with
some form of load balancing among them, which is out of scope of the present document.
2) The MW radio links are associated to the corresponding Ethernet link in the Ethernet topology (one per
direction), via the underlay attribute in the Ethernet TE topology model [2].
The node-id attribute of the microwave topology and the node-id attribute in the Ethernet topology shall be
set to the same value, consisting of a dotted quad of numbers between 0 and 255. For ease of identification,
this value should coincide with the IPv4 management plane address of the corresponding physical microwave
NE.
ETSI
12 ETSI GS mWT 024 V1.2.1 (2023-04)
4.2.1.3 Ethernet TE Topology
4.2.1.3.1 Introduction
The Ethernet TE topology model provides information about TE nodes (which correspond 1:1 to the MW nodes),
eLTPs, Ethernet links connecting the NEs and providing the possible path(s) over which the Ethernet services can be
provisioned:
a) The Ethernet links are associated to the corresponding Microwave link (one per direction), via the underlay
attribute in the Ethernet TE topology model [2] and [1].
b) Internal (or intra-domain) Ethernet links connect the ethernet eLTPs belonging to one another.
c) External (or access or inter-domain) Ethernet links connect an eeLTP to an external equipment.
d) The node-id attribute of the microwave topology and the node-id attribute in the Ethernet topology shall be
set to the same value, consisting of a dotted quad of numbers between 0 and 255. For ease of identification,
this value should coincide with the IPv4 management plane address of the corresponding microwave NE.
The Ethernet TE topology contains information about all eLTPs available on the NEs, regardless if these are connected
to another MW NE, to any other external device, or even are unconnected. The MDSC determines which eLTPs are
relevant for its purposes, based on the existence of Ethernet links connected to them.
Clause 4.2.1.3.2 discusses how the MDSC can differentiate eeLTPs from eLTPs that are unconnected. eLTPs connected
to a faulty Ethernet link appear as unconnected, regardless of the internal or external nature of the faulty link.
4.2.1.3.2 External Ethernet Links and Inter-Domain Connectivity
One of the main purposes of the MDSC is to coordinate and provision services across multiple domains. Since no PNC
can know or manage the inter-domain links, these have to be modelled by the MDSC based on information about the
eeLTPs from the corresponding domains.
Two attributes of an eLTP concur in defining it as an eeLTP:
1) The inter-domain-plug-id attribute shall be present, and shall have a network-wide-unique value:
a) If the eLTP is not an eeLTP, the attribute shall be missing.
2) The client-facing attribute shall be present, and shall have the Boolean value "true":
a) If the eLTP is not an eeLTP, the attribute shall be missing or, if present, it shall assume the Boolean
value "false".
Both attributes may be configured either manually or automatically. Both attributes shall be managed in the same way,
either both manually, or both automatically.
In case of automatic configuration:
1) The algorithm specified in Annex B shall be used to calculate the inter-domain-plug-id attribute,
regardless of the presence and value of the client-facing attribute.
2) The PNC may be able to infer the edge nature of the eLTP independently from the inter-domain-plug-id
attribute's successful configuration, but the inter-domain-plug-id attribute shall always have priority to
determine if an eLTP is an eeLTP actually connected to an external domain.
It may happen that an eLTP is changed to eeLTP, or vice-versa, during the lifetime of the network, reflecting the
changes in physical topology (e.g. addition or removal of links and/or equipment, delays in configuring external NEs,
etc.). The MDSC shall update its picture of the network by regularly uploading it or by subscribing to the relevant
attributes' notifications.
ETSI
13 ETSI GS mWT 024 V1.2.1 (2023-04)
4.2.2 Ethernet Service Configuration
4.2.2.1 Ethernet Services
The service types specified in this Profile are VLAN-based Ethernet services as defined in [3]. The present document
will refer to the point-to-point services as E-LINE and the multi-point-to-multi-point as E-LAN, following the
terminology of [i.2]. This profile does not cover rooted-multipoint services ("E-TREE").
The type of service is determined by the value of the etht-svc-type attribute of the Service Model (see
clause A.2.4):
• E-LINE services: "p2p-svc"
• E-LAN services: "mp2mp-svc"
Details about the domain-internal transport mechanism (which may not even be ethernet-based), or where which VLAN
operations are performed within the MW domain may not be exposed over the MPI to the MDSC, depending on the
adopted Abstraction Level (see clause 4.3).
Ethernet services can be established between any eLTPs described in the retrieved Ethernet TE topology.
Whereas the overall goal of the MDSC is to coordinate E2E services across multiple domains, i.e. between eeLTPs. It
may be of practical value to create services between eLTPs, either for testing purposes, or in case of time delays in the
coordination with other domains (e.g. delayed configuration of the LLDP protocol on the external domain's eLTP).
But in general, the objects of the present document are the data services between two or more eLTPs and/or eeLTPs,
falling into one of the 6 Types defined in Table 4.2.2.1.1. In case of E-LINE, the service has two and only two
eLTPs/eeLTPs, whereas in case of E-LAN the service has at least two eLTPs/eeLTP (see [i.2] for the difference
between a point-to-point EVC and a multipoint to multipoint EVC associating two UNIs). In case of E-LAN,
Table 4.2.2.1.1 defines the Type of Service to be implemented between each possible couple of eLTPs.
Table 4.2.2.1.1 Service Classification
Service Type Classification @ Classification @ Reference Remarks
LTP A LTP Z
Type 1 Untagged Untagged C-VLAN bridge, Provider Note 2.
bridge as per [18].
MEF 10.3 [i.3].
Type 2 Untagged C-VLAN C-VLAN bridge, Provider Note 2.
bridge as per [18].
MEF 10.3 [i.3].
Type 3 Untagged S-VLAN Provider bridge as per [18]. Note 2.
Type 4 C-VLAN C-VLAN C-VLAN bridge, Provider The C-VLAN values at the two
bridge as per [18]. edges can be the same (C-VLAN
MEF 10.3 [i.3] preservation) or different (no
C-VLAN preservation).
Type 5 S-VLAN S-VLAN Provider bridge as per [18]. The S-VLAN values at the two
edges can be the same (S-VLAN
preservation) or different (no
S-VLAN preservation).
The C-VLAN is ignored but always
preserved, if present.
Type 6 S-VLAN C-VLAN Provider bridge as per [18]. The C-VLAN is always preserved.
NOTE 1: A VLAN for internal path selection is used by the bridges within the network, but its configuration is performed
autonomously by the PNC based on the equipment characteristics.
NOTE 2: When the Classification is Untagged, in the egress direction all the frames are transmitted as untagged. In the
ingress direction, only untagged frames are expected to be received. However, if received, priority-tagged
frames and frames tagged with the VLAN ID equal to the LTP's port VID also matches this classification, as
specified in MEF 10.3 [i.3], and are forwarded as specified for the service configuration.
NOTE 3: In case of E-LAN, if the Service Type between at least one pair of the eLTPs/eeLTPs requires a Provider
Bridge, then the whole service is considered to require support for the Provider Bridge capability.

Services shall not be accepted by the PNC if the network does not support them. See Annex C for examples and
network capabilities as visible to the MDSC via the eeLTPs.
ETSI
14 ETSI GS mWT 024 V1.2.1 (2023-04)
The untagged classification is configured by the MDSC by configuring the same VID value for both the port VLAN ID
and the C-VLAN ID used by service classification at a given LTP. In case of tagged classification, the MDSC shall
configure the port VLAN ID with a different value than the C-VLAN ID used by the service classification at a given
LTP.
As a general approach, the Profile does not allow the MDSC to specify in detail if and where VLAN operations (VLAN
tag push, pop, swap) are performed: this shall be left to the PNC to decide, based on the equipment characteristics and
the planning guidelines used in the given network.
4.2.2.2 Bandwidth Profiles
4.2.2.2.1 BWPs in the Ethernet TE Topology
In the Ethernet TE topology the eLTPs may have an associated BWP. This may be a single BWP for both ingress and
egress (symmetrical case), or a set of two BWPs, one for ingress and one for egress (asymmetrical case).
The asymmetrical case has an application in WBH networks, for example to set the traffic shaping parameters on the
interconnection from a high-capacity MW link towards a lower capacity MW link. The physical ethernet
interconnection between MW NEs has a usually fixed and symmetrical throughput (e.g. 100, 1 000 or 10 000 Mbps),
whereas the modem capacity over the air depends on the given link configuration, and is usually smaller than the
physical ethernet link throughput. Setting the egress capacity to a lower value, matching the speed of the slower link,
translates in traffic shaping being applied.
Internal and external (access or inter-domain) eLTPs are managed differently:
1) The BWPs for internal eLTPs are managed by the PNC, and used by the MDSC as a reference to correctly
dimension the BWP of the services it provisions across those eLTPs. There is no reason for the MDSC to
change those BWPs, since they reflect the underlying network dimensioning that is based a.o. on the MW link
engineering (MW throughput), which is not controlled by the MDSC. The MDSC may however use this
information, if available, to improve the E2E service provisioning and the bandwidth utilization over the
network.
2) The BWPs for eeLTPs (both access and inter-domain) are managed by the MDSC. This allows to coordinate
parameters such as traffic shaping from one domain to the next.
NOTE: The BWPs associated to the eLTPs in the Ethernet TE Topology have no explicit relation to the service
BWPs.
4.2.2.2.2 BWPs in the Service Model
The Service model in principle allows two ways to specify BWPs: either locally to each service, or globally. As per the
present document, the global definition of BWPs shall be used exclusively:
1) The set of global BWPs to be used in the network shall be maintained independently from any service
instance.
2) Each end point of a service instance shall refer to the global BWP(s).
This allows to easily standardize the types of BWPs and maintain consistency across the network.
Both symmetrical and asymmetrical BWP types are available (see also Figure 4.2.2.2.3.1):
1) Symmetrical BWP (example: B2B data services):
The ingress-egress-bandwidth-profile shall be configured by the MDSC, and shall be the same at
both end points.
2) Asymmetrical BWP (example: Mobile Backhaul):
Both the ingress-bandwidth-profile and the egress-bandwidth-profile shall be configured by the
MDSC, and shall correspond at both end points A and Z:
a) The A-ingress and Z-egress BWP shall be the same.
b) The Z-ingress and A-egress BWP shall be the same.
ETSI
15 ETSI GS mWT 024 V1.2.1 (2023-04)
c) The BWPs at points 2.a and 2.b above are in general different.
The management of BWPs is restricted by the following rules:
1) Since a given BWP may be referenced to by a large and varying number of service instances, it shall be up to
the MDSC to ensure that no BWP is deleted unless there is no service instance referring to it.
2) The BWP attributes are marked as "rw" in the model, since in general BWPs can be created, deleted and
modified. However, if an existing BWP is modified, this will in general require the PNC to check a large
number of existing service instances, and possibly modify many NE configurations accordingly. This may take
a significant amount of time, and may not be successful for all services, potentially causing a transient,
unpredictable and inconsistent state across the network. Therefore, BWPs can be created and deleted, but
cannot be modified. In case an existing BWP needs to be modified, a new one shall be created, and all affected
service instances shall be updated one by one, referring to the new BWP, before the old one can be deleted,
thus ensuring that the MDSC is always in full control of the network.
4.2.2.2.3 Full Example o
...