COM 15 – LS 277 – E
INTERNATIONAL TELECOMMUNICATION UNION
TELECOMMUNICATION
STANDARDIZATION SECTOR
English only
STUDY PERIOD 2009-2012
Question(s):
Original: English
10/15
Geneva, 14-25 February 2011
LIAISON STATEMENT
Source:
ITU-T Study Group 15
Title:
E-OTN service interfaces
LIAISON STATEMENT
For action to:
IEEE 802.1
For comment to:
-
For information to: MEF
Approval:
Agreed to at Study Group 15 meeting (Geneva, 14-25 February 2011)
Deadline:
6 June 2011
Contact:
Huub van Helvoort
Huawei Technologies Ltd.
PR China
Tel: +31 649248936
Email: hhelvoort@huawei.com
Introduction
Study is underway in Question 10 of ITU-T Study Group 15 (Q10/15) on what additions to ITU-T
Rec. G.8012 Ethernet UNI and NNI would be required to support all MEF services and 802.1
service interfaces for Ethernet over OTN (Optical Transport Network). S-Tags will be used on the
EOTN internal interfaces to identify the service VLAN signals (MEF: Ethernet Connection signals)
when those are multiplexed into point-to-point OTN ODU connections. Note that the EOTN does
not contain B-VLANs; the role of the B-VLANs is performed by the ODUs. The EOTN provides as
such a flat Ethernet architecture containing a single service VLAN layer and differs here from the
PBN/PBBN architecture which contains two service layers (service VLAN, backbone service
instance).There are several options in defining this single service VLAN layer for which we are
requesting your advice. The material in this liaison statement is work in progress, and no decisions
have been made by Q10/15.
Q10 has no intent to change the functionality of 802.1 bridging with this work. ITU-T Q10/15
wants to work within the constraints of IEEE 802.1Q VLAN Bridging.
The EOTN architecture complies with the MEF Global Interconnect architecture, and includes an
“Ethernet Services layer” which provides for S-Tagged Ethernet Connections (EC) and an OTN
based “Transport Services layer” in which point-to-point ODU connections carry aggregates of
those S-Tagged ECs between Transport Bridges (TB) and Transport Edge Bridges (TEB). TB/TEBs
also support provider Network Ports (PNP) to connect with an MEF E-NNI. Figure 7 illustrates the
TB and TEB functionality in terms of 802.1Q models.
Attention: Some or all of the material attached to this liaison statement may be subject to ITU copyright. In such a case this will be
indicated in the individual document.
Such a copyright does not prevent the use of the material for its intended purpose, but it prevents the reproduction of all or part of it in a
publication without the authorization of ITU.
-2COM 15 – LS 277 – E
Ethernet services are supported in the EOTN by its S-Tagged ECs. Support of port-based,
individual C-VLAN, bundled C-VLAN and individual S-VLAN services are supported in the same
manner as in a PB network and the TEBs include the PEB functionality. Interoperability with EC
endpoints in PEB nodes is provided naturally.
Support of bundled S-VLAN and transparent services are supported by means of a MAC-in-MAC
encapsulation. Such MAC-in-MAC encapsulation may also be deployed for e.g. multipoint bundled
C-VLAN services. As the EOTN supports all Ethernet services via S-Tagged ECs and bundled SVLAN and transparent services are supported in PBBN by I-Tagged ECs, the encapsulation format
for those services is not yet clear. Multiple encapsulation formats have been identified (see problem
statement section). A single, common encapsulation format applicable in PBBN and EOTN is
preferred to support point-to-point ECs and multipoint ECs with endpoints in both the EOTN and
PBB networks. For example, for a bundled S-VLAN service the EC may have endpoints in TEB,
IBEB and IBBEB nodes, and for a transparent service the EC may have endpoints in TEB, TBEB
and TBBEB nodes.
To support such hybrid EOTN-PBBN EC (see Figure 5), an interworking function would be
required to connect the I-Tagged EC segment in the PBBN with the S-Tagged EC segment in the
EOTN. Such interworking function should support the EC’s Provider Maintenance Association
(MA) which has endpoints in the edge bridges in both the PBB and EOTN networks.
An alternative option to establish a hybrid PBBN-EOTN EC would be to deploy a PBB Backbone
VLAN as a “Service VLAN” (see Figure 6). Such “Service VLAN” would carry e.g. a single
bundled S-VLAN service or a single Transparent service and represents a S-Tagged EC segment
which naturally interworks with the S-Tagged EC segment in the EOTN. For this case, the EOTN
will be unable to interconnect with IBEB and TBEB nodes as those nodes do not support B-VLAN
endpoints.
Problem Statement
As we have indicated previously, two essential components to the problem that we are looking to
solve for EOTN are:

Transport all MEF (G.8011.x) services over OTN

Transport all 802.1 service interfaces over OTN
Within proposals we have reviewed, additional possible mapping methods are presented, including
multiple alternative methods supporting MAC-in-MAC.
1.
Figure 1 below illustrates the two encapsulation methods and associated frame formats for
the case an individual client VLAN signal is carried as a MAC-in-MAC’ed service through
the EOTN’s ETH VC (i.e. S-VLAN) layer without preserving the client VLAN’s VID, PCP
and DEI.
I. Alternative I represents the format of an ETH(SVLAN)_CI signal (which is
equivalent to the ETH(BSI)_CI signal) transporting a single client VLAN signal (i.e.
the format of this signal at the ETH(BSI) MEP input and output ports). The client
VLAN’s VID/PCP/DEI information in this mapping is not preserved. This mapping
is supported by the ETH/ETH-ea_A function. Note that the Type=89-10 field will be
removed from the frame when it would be multiplexed into a B-VLAN using an ITag; in the ETH(BVLAN)_AI this removed Type=89-10 information is represented
by UCA=0 in the I-Tag.
ITU-T\COM-T\COM15\LS\277E.DOC
-3COM 15 – LS 277 – E
II.
Alternative II represents the format of an ETH(SVLAN)_CI signal transporting a
single client VLAN signal encapsulated using an I-Tag. The client VLAN’s
VID/PCP/DEI information in this mapping is preserved in the I-SID/I-PCP/-DEI.
This mapping is supported by the ETH/ETH-eai_A function. Note that this format
can be supported in a single domain PBB network by a special configuration of a PIP
and CBP in an IB-BEB node; the PIP supports a single S-VLAN signal (inserts an ITag but no S-Tag) and the CBP connected to this PIP maps this single signal into a
B-VLAN. There is no ETH(BSI) signal in this case.
+ B-DA, B-SA
+ BSI Tag
+ B-DA, B-SA
+ TYPE
B-DA
DEI
PCP
B-SA
Type = 89-10
0
Res1
B-SA
TPID = 88-E7
B-DA
I-SID
Res2
I-SID
C-DA
C-DA
C-DA
C-SA
Type
C-SA
Type
C-SA
Type
MSDU
MSDU
MSDU
ETH_AI
ETH_AI
(I)
(II)
ETH_CI
LMA: Local MAC Address
Figure 1 – Two MAC-in-MAC based encapsulation formats of a single VLAN service signal
+ B-DA, B-SA
+ BSI Tag
+ VLAN Tag
+ B-DA, B-SA
+ TYPE
+ VLAN Tag
+ B-DA, B-SA
+ BSI Tag
B-DA
B-SA
B-DA
I-SID
B-SA
TPID = 88-E7
DEI
PCP
0
Res1
Res2
C-DA
C-DA
C-SA
TPID
C-SA
I-SID
TPID
C-DA
VID
Type
C-SA
Type
Res2
X
Type
VID
Type
MSDU
MSDU
MSDU
MSDU
ETH_CI
ETH_AI
ETH_AI
ETH_AI
X: CFI or DEI
LMA: Local MAC Address
(I)
(II)
(III)
C-SA
PCP
0
I-SID
X
C-DA
PCP
DEI
B-SA
Type = 89-10
Res1
TPID = 88-E7
B-DA
PCP
I-SID
Figure 2 – Three MAC-in-MAC based encapsulation formats of one or more VLAN service
signals
2.
Figure 2 above illustrates the three encapsulation methods and associated frame formats for
the case one or more VLAN signals are carried as a MAC-in-MAC’ed service through the
EOTN’s ETH VC (i.e. S-VLAN) layer.
I. Alternative I represents the format of an ETH(SVLAN)_CI signal (which is
equivalent to the ETH(BSI)_CI signal) transporting one or more client VLAN
signals which are encapsulated using their normal VLAN Tag (i.e. the format of this
ITU-T\COM-T\COM15\LS\277E.DOC
-4COM 15 – LS 277 – E
II.
III.
signal at the ETH(BSI) MEP input and output ports). The client VLAN’s
VID/PCP/DEI information in this mapping is preserved in the VID/PCP/DEI fields
of the VLAN Tag. This mapping is supported by the ETH/ETH-mea_A function.
Note that the Type=89-10 field will be removed from the frame when it is
multiplexed into a B-VLAN; in the ETH(BVLAN)_AI this removed Type=89-10
information is represented by UCA=0 in the I-Tag.
Alternative II represents the format of an ETH(SVLAN)_CI signal transporting one
or more client VLAN signals encapsulated using their normal VLAN Tag plus an ITag. The client VLAN’s VID/PCP/DEI information in this mapping is preserved in
the VID/PCP/DEI fields of the VLAN Tag. This mapping is supported by the
ETH/ETH-meai_A function. Note that this format can be supported in a PBB
network by a special configuration of a PIP and CBP in an IB-BEB node; the PIP
supports one or more S-VLAN signals that are mapped into one server signal and the
CBP connected to this PIP maps this single signal into a S(B)-VLAN. There is no
ETH(BSI) signal in this case.
Alternative III represents the format of an ETH(SVLAN)_CI signal transporting one
or more client VLAN signals encapsulated using the I-Tag to encapsulate and
identify each client VLAN signal. The client VLAN’s VID/PCP/DEI information in
this mapping is preserved in the I-SID/PCP/DEI fields of the I-Tag. This mapping is
supported by the ETH/ETH-eai_A function. Note that this format can be supported
in a PBB network by a special configuration of a PIP and CBP in an IB-BEB node;
the PIP supports one or more S-VLAN signals that are mapped as individual VLAN
services (I-Tag, but no S-Tag) into the PIPs output signal and the CBP connected to
this PIP maps these I-Tagged signals into a dedicated S(B)-VLAN. There are no
ETH(BSI) signals in this case.
Question
In addition to the existing services and service interfaces, it is to be decided which (if any) of these
additional encapsulation formats have to be supported in G.8012.
The workplan is to progress a revision G.8012 in 2011 with potential consent in December 2011.
We would appreciate a response on your view of these requirements in time for our next meeting on
this topic to be held June 2011.
We look forward to your reply and continued assistance.
Further figures
ITU-T\COM-T\COM15\LS\277E.DOC
-5COM 15 – LS 277 – E
Figure 3 – MEF’s Carrier Ethernet Global Interconnect basic structure
Figure 4 – Transport Bridges (TB) and Transport Edge Bridges (TEB)
Figure 5 – EOTN-PBBN hybrid EC (S-Tagged EC segments & I-Tagged EC segments)
ITU-T\COM-T\COM15\LS\277E.DOC
-6COM 15 – LS 277 – E
Figure 6 – PBBN-EOTN hybrid EC (S-Tagged EC segments only)
ITU-T\COM-T\COM15\LS\277E.DOC
-7COM 15 – LS 277 – E
Transport Edge Bridge
Transport Bridge
Line Ports
Line Ports
S-Tagged LANs
PNP
PNP
PNP
SNP
SNP
PNP
To/from IBEB &
TBEB & BBEB
???
???
ONP
PEP C-VLAN
Component CEP
CNP
PEP
Port Based Service Interface
(un- C-, priority-S- I-Tagged)
Remote Customers C-Tagged
service interface
PEP C-VLAN
Component CEP
PEP
CNP
CNP
???
I-Tagged LANs
OTN ADMs/XCs
ONP
(P2P ODUs)
ONP
SDH ADMs/XCs
(P2P VCs)
CNP
Remote Customer Portbased Service Interface
Remote Customers S-Tagged
Service interface
MTNP
MTNP
MTNP
MPLS-TP P nodes
(P2P transport-LSPs)
PAP
Port-based, S- & C-Tagged
Service Interface
(S-, S+C-Tagged)
RCAP
S-VLAN
Component
PNP
I-Tagged service interface
(I-Tagged)
CBP
?
CNP
CBP
PIP
CNP
PIP
Port Based Service Interface
(un-, C-, priority-S- I-Tagged)
CNP
CNP
Remote Customers C-Tagged
service interface
IComponent CNP
SNP
C-Tagged Service Interface
(un-, priority-C-, C-Tagged)
PEP C-VLAN
Component CEP
PEP
CNP
PEP C-VLAN
Component CEP
PEP
CNP
CNP
MTNP
PAP
Individual or bundled I-Tagged Services
SNP
SNP
S-Tagged Service Interface
(S-Tagged)
Individual S-VLAN Service
CNP
To/from IBEB &
TBEB & BBEB
C-Tagged Service Interface
(un-, priority-C-. C-Tagged)
CNP
PNP
ONP
SNP
CNP
CNP
S-VLAN Component
S-VLAN Component
ONP
To/from
PEB & PB
& IBBEB &
MEF E-NNI
PNP
???
ONP
To/from
PEB & PB
& IBBEB &
MEF E-NNI
Tributary Port functonality
MTNP
CNP
Remote Customer Portbased Service Interface
Remote Customers S-Tagged
Service interface
PAP
S-VLAN RCAP
Component
S-Tagged Service Interface
(S-Tagged)
Port-based , S- & C-Tagged
Service Interface
(S-, S+C-Tagged)
PAP
PNP
MTNP
CNP
TPIP Component CNP
CBP
TPIP Component CNP
?
Transparent Service Interface
(un-, C-, S-, I-Tagged)
Transparent Service Interface
(un-, C-, S-, I-Tagged)
Figure 7 – Transport Bridge (TB) and Transport Edge Bridge (TEB) funtionality
_______________________
ITU-T\COM-T\COM15\LS\277E.DOC