Presentation is loading. Please wait.

Presentation is loading. Please wait.

Extending OTN Standards to Support Ethernet Services Maarten Vissers.

Similar presentations


Presentation on theme: "Extending OTN Standards to Support Ethernet Services Maarten Vissers."— Presentation transcript:

1 Extending OTN Standards to Support Ethernet Services Maarten Vissers

2 Geneva, 27 May 2010 2 Disclaimer This document complements liaison statement COM15 – LS140 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

3 Geneva, 27 May 2010 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 Geneva, 27 May 2010 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 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.

5 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 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 Geneva, 27 May 2010 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 typesETH_CI 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

7 Geneva, 27 May 2010 7 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

8 Geneva, 27 May 2010 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 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 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 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 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 Geneva, 27 May 2010 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 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 clients This minimal set is to be defined ETH VC MAC Relay PB, PBB Facing Port OTN Network Port Ethernet NNI ETH VC Component ODU_CI OTN Network Port ODU_CI ETH VC Network Port

13 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 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 MAC Relay (V-)UNI Facing Port UNI or V-UNI (V-)UNI-N Port ETH VC Network Port ETH VC MAC Relay

14 Geneva, 27 May 2010 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 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 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 Geneva, 27 May 2010 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 VCs client signal should be a supported client signal of the node (see for an overview)

17 Geneva, 27 May 2010 17 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?

18 Geneva, 27 May 2010 Backup

19 Geneva, 27 May 2010 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 Geneva, 27 May 2010 20 Ethernet services over OTN examples OTN S-Tagged LAN PBN S-Tagged LAN PBN PB I-Tagged LAN PBBN B- BEB S-Tagged LAN PBN PB I-Tagged LAN PBBN B- BEB I-Tagged LAN PBBN 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 VCC 1 ETH VCC 4 LAN ETH VCC 5 ETH VCC 6 PB ETH VCC 7

21 Geneva, 27 May 2010 21 Service types on Ethernet UNIs/V-UNIs UNI Link 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 UNI Link ETH_CI service UNI Link Bit/CodeWord stream service UNI Link ETH_CI service (V-)UNI Link ETH_CI service Transparent service Port based service C-Tagged service S-Tagged service I-Tagged service C-Tagged service I-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

22 Geneva, 27 May 2010 22 Service encapsulation in Ethernet based VC layer Ethernet VC layer MSDU DA/SA MSDU C-Tag DA/SA MSDU S-Tag DA/SA MSDU S-Tag DA/SA C-Tag MSDU I-Tag DA/SA MSDU S-Tag DA/SA I-Tag Ethernet VC layer Type 89-10 DA/SA Type 89-10 DA/SA MSDU DA/SA MSDU C-Tag DA/SA MSDU S-Tag DA/SA MSDU S-Tag DA/SA C-Tag MSDU I-Tag DA/SA MSDU 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 OAM DA/SA TYPE 89-02 OAM DA/SA TYPE 89-02 Encapsulated client information Y.1731 G.8021 G.8031 G.8051 Y.1731 G.8021 G.8031 G.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

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

24 Geneva, 27 May 2010 24 ETH VC encapsulation in OTN LO ODU layer 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 Ethernet VC layer Transmission Media ETH VC Tag + MAC FCS GFP-F Header Wavelength HO-ODU LO-ODU OTN A/GMP OAM DA/SA TYPE 89-02 ETH VC encapsulation headers/trailers

25 Geneva, 27 May 2010 25 MSDU DA/SA MSDU C-Tag DA/SA MSDU S-Tag DA/SA MSDU S-Tag DA/SA C-Tag MSDU I-Tag DA/SA MSDU S-Tag DA/SA I-Tag OAM DA/SA TYPE 89-02 Encapsulated ETH VC information Eth VC Tag GFP Header 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 MSDU DA/SA MSDU C-Tag DA/SA MSDU S-Tag DA/SA MSDU S-Tag DA/SA C-Tag MSDU I-Tag DA/SA MSDU 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 OAM DA/SA TYPE 89-02 Eth VC Tag Encapsulated ETH VC information GFP Header MAC FCS One tag for all

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

27 Geneva, 27 May 2010 27 Node type UNI-N Port type Service typeUNI or V-UNI Tagging UnCPCSPSS(c)IS(i)[s]C[s]I PEBCNP1:1 Port-based XXXX------ 1:1 S-Tagged ----XX-X-- CEP+PEP+CNP1:1, n:1 C-Tagged XXX------- I-BEBCNP+PIP1:1 Port-based XXXX-X-X-- 1:1, n:1 S-Tagged ----XX-X-- B-BEBCBP1:1 I-Tagged ------X--- T-BEBCNP-T+PIP1:1 Transparent XXXXXX-X-- IB-BEB TECNP+PIP TE1:1 Port-based XXXX------ 1:1 S-Tagged ----XX-X-- PTN NT EOTN NT Universal (V-)UNI-N 1:1 Transparent XXXXXXXX-- 1:1 Port-based XXXXXXXX-- 1:1, n:1 S-Tagged ---XXX-X-- 1:1, n:1 C-Tagged 1:1, n:1 I-Tagged XXX---X-XX 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 Service types supported by node/port type


Download ppt "Extending OTN Standards to Support Ethernet Services Maarten Vissers."

Similar presentations


Ads by Google