Extending OTN Standards to Support Ethernet Services - PowerPoint PPT Presentation

About This Presentation
Title:

Extending OTN Standards to Support Ethernet Services

Description:

Extending OTN Standards to Support Ethernet Services Maarten Vissers * Disclaimer This document complements liaison statement COM15 LS140 It presents further ... – PowerPoint PPT presentation

Number of Views:103
Avg rating:3.0/5.0
Slides: 28
Provided by: MVis5
Learn more at: https://www.ieee802.org
Category:

less

Transcript and Presenter's Notes

Title: Extending OTN Standards to Support Ethernet Services


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

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

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

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 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
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 VCMAC Relay
UNI or V-UNI
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

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

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
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 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
21
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
22
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
23
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
24
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
25
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
26
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
27
Service typessupported by node/port type
Node type UNI-N Port type Service type UNI or V-UNI Tagging UNI or V-UNI Tagging UNI or V-UNI Tagging UNI or V-UNI Tagging UNI or V-UNI Tagging UNI or V-UNI Tagging UNI or V-UNI Tagging UNI or V-UNI Tagging UNI or V-UNI Tagging UNI or V-UNI Tagging
Node type UNI-N Port type Service type Un CP C SP S S(c) I S(i) sC sI
PEB CNP 11 Port-based X X X X - - - - - -
PEB CNP 11 S-Tagged - - - - X X - X - -
PEB CEPPEPCNP 11, n1 C-Tagged X X X - - - - - - -
I-BEB CNPPIP 11 Port-based X X X X - X - X - -
I-BEB CNPPIP 11, n1 S-Tagged - - - - X X - X - -
B-BEB CBP 11 I-Tagged - - - - - - X - - -
T-BEB CNP-TPIP 11 Transparent X X X X X X - X - -
IB-BEB TE CNPPIP TE 11 Port-based X X X X - - - - - -
IB-BEB TE CNPPIP TE 11 S-Tagged - - - - X X - X - -
PTN NTEOTN NT Universal (V-)UNI-N 11 Transparent X X X X X X X X - -
PTN NTEOTN NT Universal (V-)UNI-N 11 Port-based X X X X X X X X - -
PTN NTEOTN NT Universal (V-)UNI-N 11, n1 S-Tagged - - - X X X - X - -
PTN NTEOTN NT Universal (V-)UNI-N 11, n1 C-Tagged11, n1 I-Tagged X X X - - - X - X X
Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service Un Untagged, CP C-Priority-Tagged, C C-Tagged, SP S-Priority-Tagged, S(c) SC-Tagged, I I-Tagged, S(i) SI-Tagged, sC SC-Tagged with S-Tag terminated and C-Tagged instance taken as service, sI SI-Tagged with S-Tag terminated and I-Tagged instance taken as service 11 individual service, n1 bundled service
Write a Comment
User Comments (0)
About PowerShow.com