Extending OTN Standards to Support
Ethernet Services
Maarten Vissers
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 802.1
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
Geneva, 27 May 2010
2
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
)
Geneva, 27 May 2010
3
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 802.1
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.8051. 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.
Geneva, 27 May 2010
4
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
Geneva, 27 May 2010
5
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
Geneva, 27 May 2010
for an illustration of those service types
6
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
Geneva, 27 May 2010
7
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
Geneva, 27 May 2010
8
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
Geneva, 27 May 2010
9
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.
Geneva, 27 May 2010
10
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
Geneva, 27 May 2010
11
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)
ETH VC
The “ETH VC Component”
Network
Reserved Address set
Port
ETH VC Component
should be minimized to
ETH VC
provide maximum
MAC Relay
transparency for clients
OTN
PB, PBB
OTN
This minimal set is to be
Network
Facing
Network
defined
Port
Port
Port
Geneva, 27 May 2010
Ethernet NNI
ODU_CI
ODU_CI
12
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
Geneva, 27 May 2010
UNI or V-UNI
ETH VC
Network
Port
ETH VC
MAC Relay
13
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
Geneva, 27 May 2010
14
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
Geneva, 27 May 2010
15
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)
Geneva, 27 May 2010
16
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?
Geneva, 27 May 2010
17
Backup
Geneva, 27 May 2010
ETH_CI and ETH_AI
ETH Adapted
Information (AI)
MAC_SDU
Encapsulated client
OAM: APS, MCC, CSF
SA
DA
Priority
Drop Eligible
Geneva, 27 May 2010
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
19
Ethernet services
over OTN examples
.1QN
.1QN
.1Q
PBBN
BBEB
C-Tagged
LAN
LAN
C-Tagged
LAN
I-Tagged BLAN
I-Tagged
LAN
PBN
BEB
OTN
PB
S-Tagged
LAN
PBBN
PBBN
S-Tagged
LAN
ETH VCC 4
PB
BI-Tagged
BEB LAN
PBN
S-Tagged
LAN
PB
.1Q
.1QN
Geneva, 27 May 2010
.1Q
C-Tagged
LAN
LAN
PBN
20
Service types
on Ethernet UNIs/V-UNIs
UNI Link
UnTagged or Priority-Tagged
ETH_CI
UNI Link
UNI Link
ETH_CI
service
ETH_CI
service
ETH_CI
service
ETH_CI
service
Bit/CodeWord
stream service
Transparent service
Port based service
EPL Type 2
EPL Type 2/TT
EPL Type 1, EVPL Type 2
EPT, EVPT Type 2
EPLAN, EVPLAN Type 2
S- + C-Tagged or
S- + I-Tagged
ETH_CI
(V-)UNI
Link
UNI Link
UNI Link
UNI Link
Geneva, 27 May 2010
UNI Link
UNI Link
UNI Link
ETY_CI or ETH_CI
service
C-Tagged or S-Tagged or
I-Tagged or B-Tagged
ETH_CI
ETH_CI
service
ETH_CI
service
C-Tagged service
S-Tagged service
I-Tagged service
EVPL Type 1/3
EVPT Type 1/3
EVPLAN Type 1/3
C-Tagged service
I-Tagged service
EVPL Type 1/3
EVPT Type 1/3
EVPLAN Type 1/3
21
Service encapsulation
in Ethernet based VC layer
MSDU
MSDU
C-Tag
S-Tag
C-Tag
S-Tag
I-Tag
I-Tag
S-Tag
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
MSDU
DA/SA
OAM
TYPE 89-02
MSDU
MSDU
MSDU
Y.1731
G.8021
G.8031
G.8051
Ethernet VC layer
DA/SA
MSDU
Encapsulated
client information
Best encapsulation for RMP
E-Tree and MP2MP E-LAN
services supported by rmp
and mp2mp ETH VC
connections
Geneva, 27 May 2010
Encapsulated
client information
MSDU
MSDU
MSDU
Sufficient encapsulation for
P2P E-LINE and P2MP ETree services supported by
p2p and p2mp ETH VC
connections
MSDU
MSDU
C-Tag
S-Tag
C-Tag
S-Tag
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
DA/SA
OAM
TYPE 89-02
DA/SA
Ethernet VC layer
I-Tag
I-Tag
S-Tag
Y.1731
G.8021
G.8031
G.8051
22
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
VC Type I
Eth
1:1 or n:1
Ethernet Virtual Channel layer (ETH VC)
VC Type II
EPT
EPLAN
1:1
n:1
LO ODU layer
n:1
HO ODU layer
OTU layer
OCh layer
OTU layer
OCh layer
OTN transmission media layers
Geneva, 27 May 2010
OMSn+OTSn or OPSn or OPSMnk
UNI specific EVC
server layers
UNI specific EVC
server layers
EVPL
EVPT
EVPLAN
Eth
23
ETH VC encapsulation
in OTN LO ODU layer
OAM
Ethernet VC layer
TYPE 89-02
DA/SA
ETH VC Tag + MAC FCS
GFP-F Header
LO-ODU
OTN
A/GMP
HO-ODU
Wavelength
Transmission
Media
Geneva, 27 May 2010
ETH VC encapsulation headers/trailers
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
24
ETH VC encapsulation
MAC FCS
MAC FCS
MAC FCS
MSDU
MSDU
MAC FCS
MAC FCS
MAC FCS
MSDU
C-Tag
MSDU
C-Tag
S-Tag
S-Tag
MSDU
I-Tag
MSDU
I-Tag
S-Tag
MAC FCS
Encapsulated
ETH VC information
OAM
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
Eth VC Tag can not be a
C-Tag, S-Tag or I-Tag
MAC FCS
MAC FCS
MSDU
MSDU
C-Tag
S-Tag
C-Tag
S-Tag
I-Tag
I-Tag
S-Tag
DA/SA
TYPE 89-02 Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
Eth VC Tag Eth VC Tag
Eth VC Tag
Eth VC Tag Eth VC Tag Eth VC Tag Eth VC Tag
Eth VC Tag should be a
new Tag
Encapsulated
ETH VC information
One tag for all
MAC FCS
MAC FCS
MAC FCS
MAC FCS
MSDU
OAM
DA/SA
DA/SA
DA/SA
DA/SA
MAC FCS
MSDU
DA/SA
MSDU
DA/SA
MSDU
DA/SA
GFP Header GFP Header GFP Header GFP Header GFP Header GFP Header GFP Header
Geneva, 27 May 2010
25
PTN
NT
PTN
ETM-n with
NT
I-Tagged
Universal
ETH VCs
Eth UNI
ETM-n with IB-BEB
TE
B-BEB
S-Tagged
ETH VCs
A
Universal
Eth UNI
Eth UNI
B
I-BEB
I-Tagged
ETH VCs
Eth UNI
C
T-BEB
B-BEB
B-BEB
PBBN
BCB
Eth UNI
Eth UNI
D
S-Tagged
PEB
E
Eth UNI
N
S-Tagged
ETH VCs
B-BEB
I-Tagged
ETH VCs
IB-BEB
TE
PBBTEN
BCB
TE
IB-BEB
TE
M
L
Universal
Eth UNI
EOTN
EOTN
ETH VCs
EOTN XC
PB
EOTN
ETM-n with
S-Tagged
ETH VCs
PB
Eth VC Tag
S-Tagged
ETH VCs
PB
OTN
I-Tagged ETH VCs
Universal
Eth UNI
G
EOTN
EOTN
EOTN
EOTN
I-BEB
ETM-n with
ETH VCs
S-Tagged ETH VCs
Eth UNI
PB
=
K
EOTN
OTN
PTN
NT
F
EOTN
PB
Universal
Eth UNI
OTN
EOTN XC
PBN
OTN
BCB
Geneva, 27 May 2010
H
Eth UNI
PEB
OTM-0 with
ETH VCs
EOTN
NT
J
Universal
Eth UNI
PTN
NT
I
Universal
Eth UNI
26
Service types
supported by node/port type
Node
type
PEB
I-BEB
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
1:1 Port-based
X
X
X
X
-
-
-
-
-
-
1:1 S-Tagged
-
-
-
-
X
X
-
X
-
-
CEP+PEP+CNP
1:1, n:1 C-Tagged
X
X
X
-
-
-
-
-
-
-
CNP+PIP
1:1 Port-based
X
X
X
X
-
X
-
X
-
-
1:1, n:1 S-Tagged
-
-
-
-
X
X
-
X
-
-
CNP
B-BEB
CBP
1:1 I-Tagged
-
-
-
-
-
-
X
-
-
-
T-BEB
CNP-T+PIP
1:1 Transparent
X
X
X
X
X
X
-
X
-
-
IB-BEB TE
CNP+PIP TE
1:1 Port-based
X
X
X
X
-
-
-
-
-
-
1:1 S-Tagged
-
-
-
-
X
X
-
X
-
-
1:1 Transparent
X
X
X
X
X
X
X
X
-
-
1:1 Port-based
X
X
X
X
X
X
X
X
-
-
1:1, n:1 S-Tagged
-
-
-
X
X
X
-
X
-
-
1:1, n:1 C-Tagged
1:1, n:1 I-Tagged
X
X
X
-
-
-
X
-
X
X
PTN NT
EOTN NT
Universal
(V-)UNI-N
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
Geneva, 27 May 2010
27