Extending OTN Standards to Support Ethernet Services

1
Extending OTN Standards to Support Ethernet
Services

• Maarten Vissers

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 )

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.
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

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,
  SC-Tagged LANs, I-Tagged LANs and SI-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
Service encapsulation

• The OTN should be able to accept the customers
  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 customers 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
• customers 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

7
OTN architectureextension

• 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

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

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.

10
ETH VC managementand 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

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)
• The ETH VC ComponentReserved 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 VCMAC Relay
PB, PBB Facing Port
OTN Network Port
OTN Network Port
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
ETH VC Network Port
ETH VCMAC Relay
UNI or V-UNI
13
Interoperability with802.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

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

15
ETH VC termination inPEB, 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 VCs client signal should be a supported
  client signal of the node (see for an
  overview)

16
Summary

• The addition of one ETH (VC) layer on top of the
  OTNs 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 cant 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?

17
Backup
18
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

19
Ethernet servicesover OTN examples
.1QN
.1QN
PBBN
.1Q
.1Q
C-Tagged LAN
B-BEB
LAN
C-Tagged LAN
PBBN
OTN
I-Tagged LAN
I-Tagged LAN
B-BEB
PBN
PBN
PB
S-Tagged LAN
S-Tagged LAN
PB
S-Tagged LAN
PBBN
PBN
PB
B-BEB
I-Tagged LAN
C-Tagged LAN
LAN
.1Q
.1QN
20
Service typeson 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
(V-)UNILink
UNI Link
UNI Link
ETH_CI service
ETH_CI service
ETH_CI service
ETY_CI or ETH_CI service
Transparent service Port based service
C-Tagged service S-Tagged service I-Tagged service
C-Tagged service I-Tagged service
Bit/CodeWord stream service
EPL Type 2EPL Type 2/TT
EPL Type 1, EVPL Type 2EPT, EVPT Type 2 EPLAN,
EVPLAN Type 2
EVPL Type 1/3EVPT Type 1/3EVPLAN Type 1/3
EVPL Type 1/3EVPT Type 1/3EVPLAN Type 1/3
21
Service encapsulationin 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
Y.1731 G.8021 G.8031 G.8051
Ethernet VC layer
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
Y.1731 G.8021 G.8031 G.8051
Ethernet VC layer
22
OTN architecturewith additional ETH VC layer
Additional VC layer
Ethernet-UNI
Ethernet-UNI
UserNetwork
UserNetwork
Optical Transport Network
Customer Ethernet layer
Eth
Eth
11 or n1
11 or n1
Ethernet Virtual Channel layer (ETH VC)
VC Type I
VC Type II
Eth
Eth
EVPL EVPTEVPLAN
EPTEPLAN
n1
11
UNI specific EVC server layers
UNI specific EVC server layers
LO ODU layer
n1
HO ODU layer
OTU layer
OTU layer
OCh layer
OCh layer
OTN transmission media layers OMSnOTSn or OPSn
or OPSMnk
23
ETH VC encapsulationin OTN LO ODU layer
Ethernet VC layer
ETH VC Tag MAC FCS
ETH VC encapsulation headers/trailers
GFP-F Header
LO-ODU

• 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

A/GMP
OTN
HO-ODU
Wavelength
Transmission Media
24
ETH VC encapsulation
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
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
25
L
Universal Eth UNI
OTN Eth VC Tag
EOTN
EOTN
EOTN XC
EOTN
OTN
Universal Eth UNI
OTN
EOTN
EOTN XC
K
EOTN
OTN
OTM-0 with ETH VCs
EOTN
EOTN
EOTN NT
J
EOTN
EOTN
Universal Eth UNI
26
Service typessupported by node/port type