1. Extending OTN Standards to Support Ethernet Services
Maarten Vissers

2. Disclaimer This document complements liaison statement COM15 – LS140
It presents further details of
the Ethernet over OTN service application,
a solution proposed for this application,
a potential interoperability capability with existing 802.1Q (including amendments) edge nodes and networks
Objective of the liaison statement and this document is to collect feedback from IEEE prior to progressing the work on a solution for this application in ITU-T SG15
Currently there is no agreed solution in ITU-T SG15

3. Introduction
Recently, Optical Transport Network (OTN) capabilities have been extended to make it flexible and feature rich
OTN is now a multi-service transport network supporting multitude of services:
any type of CBR service – including 1G, 10G, 40G and 100G (a)synchronous Ethernet streams
ATM, Ethernet, MPLS, IP packet clients and Ethernet Private Line (EPL) services
Carriers demand extension of OTN standards to support Ethernet Private Tree (EPT), LAN (EPLAN) and Ethernet Virtual Private Line (EVPL), Tree (EVPT), LAN (EVPLAN) services
With the above services the OTN is able to interconnect two or more routers, Ethernet switches, PBNs, PBBNs, PBB-TENs, etc. (see )

4. Introduction
ITU-T Q.9/15 and Q.11/15 received proposals for architecture and frame formats to support EPT, EPLAN, EVPL, EVPT and EVPLAN services in OTN
The proposals are based on the addition of a well defined ETH layer on top of the OTN Lower Order ODU layer
This ETH layer is referred to as Ethernet Virtual Channel (ETH VC) layer
Q.9/15 decided to liaise these proposals to for review and feedback prior to progressing the work in Q9/15
NOTE – The definition of the ETH layer is based on IEEE Ethernet standards and extensively used in ITU recommendations G.8010/G.8021/G.8031/G The ETH MEP, MIP, Connection and Protection functions and processes defined in these recommendations are to be used without modifications. To be added is an ODU-to-ETH VC adaptation function. 4

5. Requirements
The proposals were used as a starting point for developing a set of requirements based on:
Service types to support
Service encapsulation types to support
OTN architecture extension
ETH VC encapsulation, identification and reserved address transparency
ETH VC Management
Interoperability with 802.1Q edge nodes and networks
The above items are addressed in subsequent slides

6. Service types As a general principle, the OTN should
accept customer Ethernet service signals from any type of 802.3/802.1Q UNI or V-UNI
Untagged LANs, Priority-C-Tagged LANs, C-Tagged LANs, Priority-S-Tagged LANs, S-Tagged LANs, S+C-Tagged LANs, I-Tagged LANs and S+I-Tagged LANs.
support untagged, priority tagged, single tagged and double tagged ETH Characteristic Information (ETH_CI) service types
support transparent, port-based, individual and bundled ETH_CI type services
support the 802.1Q defined ETH_CI service types
See for an illustration of those service types 6

7. Service encapsulation
The OTN should be able to accept the customer’s ETH_CI and
transport this ETH_CI without further encapsulation (peering mode)
transparent transport of the top N MEG OAM levels (e.g. MELs 7,6,5), the lower 8-N MEG OAM levels are used by the OTN
encapsulate this ETH_CI to preserve its VLAN or Service Identifier (VID/SID), Priority Code Point (PCP) and Drop Eligible Indicator (DEI) values present on the (V-)UNI (client/server mode)
transparently transfer the information in the C-, S- or I-Tag associated with the customer’s ETH_CI
encapsulate this ETH_CI within the payload of a new MAC frame
operator controlled option, beneficial in E-Tree/E-LAN service cases
limits the number of MAC Addresses to learn in a rmp or mp2mp ETH VC connection in the OTN
customer’s ETH_CI frame – with or without its Tag on the (V-)UNI – will be prepended with a TYPE, SA and DA field
See for an illustration of those service encapsulations

8. OTN architecture extension
The OTN should
support all service types by a single layer network
Restrict visibility of the different UNI interface presentations to the UNI-N ports
support the defined services by means of an additional Virtual Channel (VC) layer (see )
transport the VC signals over LO ODUk connections which interconnect VC layer switching functions
The VC layer in the OTN should
support p2p, p2mp, rmp and mp2mp VC connections to support the EVPL, E(V)PT and E(V)PLAN services
be an Ethernet (ETH) based VC layer network
deploy Y.1731 Ethernet OAM to monitor the VC connection status and performance
deploy G.8031 Ethernet linear protection switching

9. VC encapsulation
The OTN should encapsulate each ETH VC frame in the same manner, independent of the
customer service supported by the ETH VC
number of ETH VC signals (1 or n) carried in the LO ODUk connection
The encapsulation header should include fields to identify the
ETH VC to which the frame belongs
if a single ETH VC signal is carried in the LO ODUk connection (private service case) the identifier field may be set to a default null value
priority and drop eligibility of the frame
See for an illustration of ETH VC frame encapsulation

10. VC identification The OTN should
support link local ETH VC connection identifiers
Default approach to support scalability of connections in a transport network
Allows for ETH VC ID interchange at link ends under control of ETH VC connection manager
identify frames of a (p2p, p2mp, rmp and mp2mp) ETH VC connection by means of a single identifier value per link
For the case of a “multi-root rooted-multipoint” ETH VC the use of a single identifier value per link might not be possible. Instead the use of two identifier values may be required. This is under study.

11. ETH VC management and survivability
The OTN should
manage (set up, modify, tear down, configure) the ETH VC connections and their MEP and MIP functions under control of NMS and/or ASON/GMPLS
increase survivability of the ETH VC connections by means of G.8031 ETH Sub-Network Connection (SNC) protection switching and/or GMPLS based ETH VC restoration
dual homing and/or dual node interconnect (DH/DNI) methods under development in Q.9/15 should be deployed to survive multiple faults

12. ETH VC Reserved Addresses transparency
The ETH VC switching functionality in the OTN may be represented by means of an “ETH VC Component”
The “ETH VC Component” includes a MAC Relay, OTN Network Ports and optionally PB/PBB Facing Port(s)
The “ETH VC Component” Reserved Address set should be minimized to provide maximum transparency for clients
This minimal set is to be defined
ETH VC Network Port
ETH VC Component
ETH VC MAC Relay
PB, PBB Facing Port
OTN Network Port
OTN Network Port
Ethernet NNI
ODU_CI
ODU_CI

13. Universal Ethernet (V-)UNI-N port
It is an objective to specify a universal Ethernet UNI-N/V-UNI-N port which supports the set of EPT, EPLAN, EVPL, EVPT and EVPLAN services
This (V-)UNI-N port includes a (V-)UNI Facing Port, an ETH VC Network Port and a MAC Relay function
This port should be configurable to support any service type
(V-)UNI-N Port
MAC Relay
(V-)UNI Facing Port
ETH VC Network Port
ETH VC MAC Relay
UNI or V-UNI

14. Interoperability with 802.1Q edge nodes and networks
EVPL, EVPT and EVPLAN services supported by the OTN may have one or more of their UNI-N ports located outside the OTN
E.g. located in PEB, I-BEB, B-BEB, IB-BEB devices
The OTN should connect via an S- or I-Tagged LAN Ethernet NNI to those devices directly, or via an intermediate PB, PBB or PBB-TE network (see )
The ETH VC signal should in those cases be encapsulated with an S-Tag or I-Tag

15. ETH VC over PB, PBB, PBB-TE networks
Question: under which conditions can an ETH VC signal be transported through a PBN, PBBN and PBB-TEN?
In the OTN an ETH VC frame is combined with an ETH VC Tag
If an ETH VC frame is combined with an S-Tag it looks like a S-VLAN and could then be transported through a PBN via a CNP on a PB or PEB node
If an ETH VC frame is combined with an S-Tag it looks like a S-VLAN and could then be transported through a PBB-TEN via a CNP on an IB-BEB
If an ETH VC frame is combined with an I-Tag it looks like a BSI and could then be transported through a PBBN via a CBP on a B-BEB or IB-BEB

16. ETH VC termination in PEB, I-BEB, B-BEB, IB-BEB, T-BEB
Question: under which conditions can an ETH VC signal be terminated in a PEB, I-BEB, IB-BEB or T-BEB?
ETH VC frames should be S- or I-Tagged as required by those nodes
ETH VC’s client signal should be a supported client signal of the node (see for an overview)

17. Summary
The addition of one ETH (VC) layer on top of the OTN’s LO ODU layer together with ETH switching functions in a subset of OTN cross connects enables the OTN to support EPT, EPLAN, EVPL, EVPT and EVPLAN services for any of the possible service types.
A ETH VC Tag is required to mark each ETH VC frame within a LO ODU signal. It seems that this Tag can’t be one of the 802.1Q defined Tags.
The Ethernet services may have a subset of their endpoints located outside the OTN, e.g. within 802.1Q defined nodes. Interoperability between the service layer in the OTN and the service layer in a PB, PBB and PBB-TE network and/or edge node is anticipated. Under which preconditions would this be possible?

18. Backup

19. ETH_CI and ETH_AI ETH Adapted Information (AI)
MAC_SDU
Encapsulated client
OAM: APS, MCC, CSF SA DA
Priority
Drop Eligible
ETH Characteristic Information (CI)
MAC_SDU
Encapsulated client
OAM: APS, CSF, MCC
OAM: CCM, AIS, LCK, LBx, LTx, TST, LMx, DMx SA DA
Priority
Drop Eligible

20. Ethernet services over OTN examples
.1QN
.1QN
PBBN
.1Q
.1Q
C-Tagged LAN
B- BEB
LAN
ETH VCC 4
C-Tagged LAN
ETH VCC 1
ETH VCC 6
ETH VCC 3
PBBN
OTN
ETH VCC 5
I-Tagged LAN
I-Tagged LAN
B- BEB
PBN PB
ETH VCC 2
PBN
S-Tagged LAN
S-Tagged LAN
ETH VCC 7 PB
S-Tagged LAN
PBBN PB
PBN
B- BEB
I-Tagged LAN
C-Tagged LAN
LAN
.1Q
.1QN

21. Service types on Ethernet UNIs/V-UNIs
UNI Link
UnTagged or Priority-Tagged ETH_CI
UNI Link
UNI Link
C-Tagged or S-Tagged or I-Tagged or B-Tagged ETH_CI
ETH_CI service
UNI Link
UNI Link
UNI Link
S- + C-Tagged or S- + I-Tagged ETH_CI
ETH_CI service
ETH_CI service
UNI Link
UNI Link
UNI Link
(V-)UNI Link
ETY_CI or ETH_CI service
ETH_CI service
ETH_CI service
ETH_CI service
Bit/CodeWord stream service
Transparent service
Port based service
C-Tagged service
S-Tagged service
I-Tagged service
C-Tagged service
I-Tagged service
EPL Type 2 EPL Type 2/TT
EPL Type 1, EVPL Type 2 EPT, EVPT Type 2 EPLAN, EVPLAN Type 2
EVPL Type 1/3 EVPT Type 1/3 EVPLAN Type 1/3
EVPL Type 1/3 EVPT Type 1/3 EVPLAN Type 1/3

22. Service encapsulation in Ethernet based VC layer
MSDU
MSDU
MSDU
MSDU
MSDU
Encapsulated client information
MSDU
C-Tag
I-Tag
C-Tag
S-Tag
S-Tag
I-Tag
S-Tag
Sufficient encapsulation for P2P E-LINE and P2MP E-Tree services supported by p2p and p2mp ETH VC connections
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
Ethernet VC layer
Y.1731
G.8021
G.8031
G.8051
OAM
DA/SA
TYPE 89-02
MSDU
MSDU
MSDU
MSDU
MSDU
MSDU
Encapsulated client information
C-Tag
I-Tag
C-Tag
S-Tag
S-Tag
I-Tag
S-Tag
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
Type 89-10
Type 89-10
Type 89-10
Type 89-10
Type 89-10
Type 89-10
Best encapsulation for RMP E-Tree and MP2MP E-LAN services supported by rmp and mp2mp ETH VC connections
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
Ethernet VC layer
Y.1731
G.8021
G.8031
G.8051
OAM
DA/SA
TYPE 89-02

23. OTN architecture with additional ETH VC layer
Additional VC layer
Ethernet-UNI
Ethernet-UNI
User Network
User Network
Optical Transport Network
Customer Ethernet layer
Eth
Eth
1:1 or n:1
1:1 or n:1
Ethernet Virtual Channel layer (ETH VC)
VC Type I
Eth
VC Type II
Eth
EVPL
EVPT EVPLAN
EPT EPLAN
1:1
n:1
UNI specific EVC server layers
UNI specific EVC server layers
LO ODU layer
n:1
HO ODU layer
OTU layer
OTU layer
OCh layer
OCh layer
OTN transmission media layers
OMSn+OTSn or OPSn or OPSMnk

24. ETH VC encapsulation in OTN LO ODU layer
Ethernet VC layer
OAM
DA/SA
TYPE 89-02
ETH VC Tag + MAC FCS
ETH VC encapsulation headers/trailers
GFP-F Header
LO-ODU
A/GMP
ETH VC frames are Tagged and then mapped into a GFP-F frame
MAC FCS is appended to the GFP-F frame
GFP-F frame is mapped into ODU payload area
GFP Idle frames are inserted in absence of ETH VC frames
See next slide for illustrations
OTN
HO-ODU
Wavelength
Transmission Media

25. ETH VC encapsulation Eth VC Tag can not be a C-Tag, S-Tag or I-Tag
MAC FCS
MAC FCS
MAC FCS
MAC FCS
MAC FCS
MSDU
MSDU
MAC FCS
MSDU
MSDU
MSDU
MAC FCS
MSDU
Encapsulated
ETH VC information
OAM
C-Tag
I-Tag
C-Tag
S-Tag
S-Tag
I-Tag
S-Tag
TYPE 89-02
One tag for all
Eth VC Tag
Eth VC Tag
Eth VC Tag
Eth VC Tag
Eth VC Tag
Eth VC Tag
Eth VC Tag
Eth VC Tag can not be a C-Tag, S-Tag or I-Tag
Eth VC Tag should be a new Tag
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
GFP Header
GFP Header
GFP Header
GFP Header
GFP Header
GFP Header
GFP Header
MAC FCS
MAC FCS
MAC FCS
MAC FCS
MAC FCS
MSDU
MSDU
MAC FCS
MSDU
MSDU
MSDU
MSDU
C-Tag
I-Tag
Encapsulated
ETH VC information
MAC FCS
C-Tag
S-Tag
S-Tag
I-Tag
S-Tag
OAM
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
Type 89-10
Type 89-10
Type 89-10
Type 89-10
Type 89-10
Type 89-10
TYPE 89-02
One tag for all
Eth VC Tag
Eth VC Tag
Eth VC Tag
Eth VC Tag
Eth VC Tag
Eth VC Tag
Eth VC Tag
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
GFP Header
GFP Header
GFP Header
GFP Header
GFP Header
GFP Header
GFP Header

26. OTN PBN A N M PBB- TEN B PBBN L C D E K F J G H I Eth VC Tag = I-BEB
I-Tagged ETH VCs
Eth UNI
PTN NT
ETM-n with
Universal Eth UNI
B-BEB
BCB
T-BEB
I-BEB A B C D
IB-BEB TE
Eth UNI
S-Tagged ETH VCs
PTN NT
ETM-n with
Universal Eth UNI
BCB
PBB-
TEN M N L
Universal Eth UNI
OTN
Eth VC Tag
S-Tagged ETH VCs
PEB
PBN
Eth UNI
PTN NT
ETM-n with
Universal Eth UNI PB E F
EOTN
EOTN
EOTN XC
EOTN
OTN
Universal Eth UNI
OTN
EOTN
EOTN XC K
EOTN
OTN
OTM-0 with
ETH VCs
EOTN
EOTN
I-Tagged ETH VCs
Eth UNI
I-BEB G
EOTN
EOTN NT J
EOTN
PTN NT
ETM-n with
ETH VCs
Universal Eth UNI I
PEB
S-Tagged ETH VCs
Eth UNI H
Universal Eth UNI =
BCB PB

27. Service types supported by node/port type
Node type
UNI-N Port type
Service type
UNI or V-UNI Tagging Un CP C SP S
S(c) I
S(i)
[s]C
[s]I
PEB
CNP
1:1 Port-based X -
1:1 S-Tagged
CEP+PEP+CNP
1:1, n:1 C-Tagged
I-BEB
CNP+PIP
1:1, n:1 S-Tagged
B-BEB
CBP
1:1 I-Tagged
T-BEB
CNP-T+PIP
1:1 Transparent
IB-BEB TE
CNP+PIP TE
PTN NT EOTN NT
Universal (V-)UNI-N
1:1, n:1 C-Tagged 1:1, n:1 I-Tagged
Un: Untagged, CP: C-Priority-Tagged, C: C-Tagged, SP: S-Priority-Tagged, S(c): S+C-Tagged, I: I-Tagged, S(i): S+I-Tagged, [s]C: S+C-Tagged with S-Tag terminated and C-Tagged instance taken as service, [s]I: S+I-Tagged with S-Tag terminated and I-Tagged instance taken as service
1:1: individual service, n:1: bundled service