Extending OTN Standards to Support Ethernet Services
description
Transcript of Extending OTN Standards to Support Ethernet Services
Extending OTN Standards to Support Ethernet Services
Maarten Vissers
Geneva, 27 May 2010 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 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 3
Introduction
Recently, Optical Transport Network (OTN) capabilities have been extended to make it flexible and feature richOTN 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) servicesWith 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 4
IntroductionITU-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 OTNThe 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.
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 5
Requirements
The proposals were used as a starting point for developing a set of requirements based on:
Service types to supportService encapsulation types to supportOTN architecture extensionETH VC encapsulation, identification and reserved address transparencyETH VC ManagementInteroperability with 802.1Q edge nodes and networks
The above items are addressed in subsequent slides
Geneva, 27 May 2010 6
Service types
As a general principle, the OTN shouldaccept 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 typessupport transparent, port-based, individual and bundled ETH_CI type servicessupport the 802.1Q defined ETH_CI service types
See for an illustration of those service types
Geneva, 27 May 2010 7
Service encapsulationThe 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 caseslimits the number of MAC Addresses to learn in a rmp or mp2mp ETH VC connection in the OTNcustomer’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 8
OTN architectureextension
The OTN shouldsupport 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 shouldsupport p2p, p2mp, rmp and mp2mp VC connections to support the EVPL, E(V)PT and E(V)PLAN servicesbe an Ethernet (ETH) based VC layer networkdeploy Y.1731 Ethernet OAM to monitor the VC connection status and performancedeploy G.8031 Ethernet linear protection switching
Geneva, 27 May 2010 9
VC encapsulation
The OTN should encapsulate each ETH VC frame in the same manner, independent of the
customer service supported by the ETH VCnumber 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 belongsif 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 10
VC identification
The OTN should support link local ETH VC connection identifiers
Default approach to support scalability of connections in a transport networkAllows 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 11
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/GMPLSincrease 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 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 clientsThis minimal set is to be defined
ETH VCMAC Relay
PB, PBB Facing
Port
OTN Network
Port
Ethernet NNI
ETH VC Component
ODU_CI
OTN Network
Port
ODU_CI
ETH VC Network
Port
Geneva, 27 May 2010 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 servicesThis (V-)UNI-N port includes a (V-)UNI Facing Port, an ETH VC Network Port and a MAC Relay functionThis port should be configurable to support any service type
MAC Relay
(V-)UNI Facing
Port
UNI or V-UNI
(V-)UNI-N Port
ETH VC Network
Port
ETH VCMAC Relay
Geneva, 27 May 2010 14
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
Geneva, 27 May 2010 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 TagIf 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 nodeIf 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-BEBIf 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 16
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 nodesETH VC’s client signal should be a supported client signal of the node (see for an overview)
Geneva, 27 May 2010 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?
Geneva, 27 May 2010
Backup
Geneva, 27 May 2010 19
ETH_CI and ETH_AI
ETH Adapted Information (AI)
MAC_SDUEncapsulated clientOAM: APS, MCC, CSF
SADAPriorityDrop Eligible
ETH Characteristic Information (CI)
MAC_SDUEncapsulated clientOAM: APS, CSF, MCCOAM: CCM, AIS, LCK, LBx, LTx, TST, LMx, DMx
SADAPriorityDrop Eligible
Geneva, 27 May 2010 20
Ethernet servicesover OTN examples
OTNS-Tagged
LAN
PBN S-Tagged LAN
PBNPB
I-Tagged LAN PBBNB-
BEB
S-Tagged LAN
PBN
PB
I-Tagged LAN
PBBN B-BEB
I-Tagged LANPBBN
B-BEB
C-Tagged LAN
.1QN
.1Q
C-Tagged LAN
.1QN
.1Q
C-Tagged LAN
.1QN.1Q
LAN
ETH VCC 2
ETH VCC 3
ETH
VC
C 1
ETH
VC
C 4
LAN
ETH VCC 5
ETH V
CC 6
PB
ETH VCC 7
Geneva, 27 May 2010 21
Service typeson Ethernet UNIs/V-UNIs
UNI Link
UNI Link
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/3
EVPLAN Type 1/3
EVPL Type 1/3EVPT Type 1/3
EVPLAN Type 1/3
UNI Link
ETH_CI service
ETH_CI service
ETH_CI service
UNI Link
UNI Link
UNI Link
UNI Link
Bit/CodeWord stream service
UNI Link
UNI Link
ETH_CI service
ETH_CI service
(V-)UNILink
ETH_CI service
Transparent servicePort based service
C-Tagged serviceS-Tagged serviceI-Tagged service
C-Tagged serviceI-Tagged service
S- + C-Tagged or S- + I-Tagged
ETH_CI
C-Tagged or S-Tagged or I-Tagged or B-Tagged
ETH_CI
UnTagged or Priority-Tagged ETH_CI
ETY_CI or ETH_CI service
Geneva, 27 May 2010 22
Service encapsulationin Ethernet based VC layer
Ethernet VC layerEthernet VC layer
MSDUMSDU
DA/SA
MSDUMSDU
C-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
C-Tag
MSDUMSDU
I-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
I-Tag
Ethernet VC layerEthernet VC layer
Type 89-10
DA/SA
Type 89-10
DA/SA
MSDUMSDU
DA/SA
MSDUMSDU
C-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
C-Tag
MSDUMSDU
I-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
I-Tag
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
OAMOAM
DA/SATYPE 89-02
OAMOAM
DA/SATYPE 89-02
Encapsulated client information
Encapsulated client information
Y.1731G.8021G.8031G.8051
Y.1731G.8021G.8031G.8051
Sufficient encapsulation for P2P E-LINE and P2MP E-
Tree services supported by p2p and p2mp ETH VC
connections
Best encapsulation for RMP E-Tree and MP2MP E-LAN
services supported by rmp and mp2mp ETH VC
connections
Geneva, 27 May 2010 23
OTN architecturewith additional ETH VC layer
Ethernet Virtual Channel layer (ETH VC)Ethernet Virtual Channel layer (ETH VC)
Customer Ethernet layerCustomer Ethernet layer
OCh layerOCh layerOCh layerOCh layer
UserNetwork
UserNetwork
LO ODU layerLO ODU layer
Ethernet-UNI Ethernet-UNI
VC Type IVC Type II
1:1 or n:1 1:1 or n:1
n:1
n:1
1:1
Eth Eth
Optical Transport Network
HO ODU layerHO ODU layer
OTU layerOTU layerOTU layerOTU layer
OTN transmission media layersOMSn+OTSn or OPSn or OPSMnkOTN transmission media layersOMSn+OTSn or OPSn or OPSMnk
UN
I specific EV
C
server layers
UN
I specific EV
C
server layers
EPTEPLAN
EVPLEVPTEVPLAN
Eth Eth
Additional VC layer
Geneva, 27 May 2010 24
ETH VC encapsulationin OTN LO ODU layer
ETH VC frames are Tagged and then mapped into a GFP-F frameMAC FCS is appended to the GFP-F frameGFP-F frame is mapped into ODU payload areaGFP Idle frames are inserted in absence of ETH VC framesSee next slide for illustrations
Ethernet VC layerEthernet VC layer
Transmission Media
Transmission Media
ETH VC Tag + MAC FCS
GFP-F Header
WavelengthHO-ODUHO-ODU
LO-ODU
OTN A/GMP
OAMOAM
DA/SATYPE 89-02
ETH VC encapsulation headers/trailers
Geneva, 27 May 2010 25
MSDUMSDU
DA/SA
MSDUMSDU
C-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
C-Tag
MSDUMSDU
I-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
I-Tag OAMOAM
DA/SA
TYPE 89-02
Encapsulated ETH VC information
Eth VC Tag Eth VC Tag Eth VC Tag Eth VC Tag Eth VC Tag Eth VC Tag Eth VC Tag
GFP Header GFP Header GFP Header GFP Header GFP Header GFP Header GFP Header
MAC FCS
MAC FCS MAC FCSMAC FCS
MAC FCSMAC FCS
MAC FCS
One tag for all
Eth VC Tag can not be a C-Tag, S-Tag or I-Tag
Eth VC Tag should be a new Tag
ETH VC encapsulation
Type 89-10
DA/SA
Type 89-10
DA/SA
MSDUMSDU
DA/SA
MSDUMSDU
C-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
C-Tag
MSDUMSDU
I-Tag
DA/SA
MSDUMSDU
S-Tag
DA/SA
I-Tag
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
Type 89-10
DA/SA
OAMOAM
DA/SA
TYPE 89-02
Eth VC Tag Eth VC Tag Eth VC Tag Eth VC Tag Eth VC Tag Eth VC Tag Eth VC Tag
EncapsulatedETH VC information
GFP Header GFP Header GFP Header GFP Header GFP Header GFP Header GFP Header
MAC FCS
MAC FCS MAC FCSMAC FCS
MAC FCSMAC FCS
MAC FCS
One tag for all
Geneva, 27 May 2010 26
OTNEth VC Tag
Universal Eth UNI
Universal Eth UNI
OTM-0 withETH VCs
Universal Eth UNI
EOTN XC
EO
TN
XC
= BCBPB
EOTN
EOTN
OTN
EOTNOTN
OTN
EOTNNT
I-Tagged ETH VCs
Eth UNI
I-BEBG
PEB
S-Tagged ETH VCs
Eth UNI
H PTNNT
ETM-n withETH VCs
Universal Eth UNI
I
J
K
L
IB-BEBTE
Eth UNI
S-Tagged ETH VCs
PTNNT
ETM-n withS-Tagged ETH VCs
Universal Eth UNI IB-BEB
TE
IB-BEBTE
BCBTE
PBB-TEN
MN
S-Tagged ETH VCs
PEB
PBN
S-Tagged ETH VCs
Eth UNI
PTNNT
ETM-n withS-Tagged ETH VCs
Universal Eth UNI
PB
PB PB
PB
E
F
PBBN
I-Tagged ETH VCs
I-Tagged ETH VCs
Eth UNI
PTNNT
ETM-n withI-Tagged ETH VCsUniversal
Eth UNI
B-BEB
B-BEB
B-BEBBCB
B-BEBT-BEB
Eth UNI
I-BEB
A
B
CEth UNI
D EOTN
EOTN
EOTN
EOTN
EOTNEOTN
Geneva, 27 May 2010 27
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 X X X - - - - - -
1:1 S-Tagged - - - - X X - X - -
CEP+PEP+CNP 1:1, n:1 C-Tagged X X X - - - - - - -
I-BEB CNP+PIP 1:1 Port-based X X X X - X - X - -
1:1, n:1 S-Tagged - - - - X X - X - -
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 - -
PTN NTEOTN NT
Universal (V-)UNI-N
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-Tagged1:1, n:1 I-Tagged
X X X - - - X - X X
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 service1:1: individual service, n:1: bundled service
Service typessupported by node/port type