Ethernet over Transport

White Paper

PM
35
7:
:4
04
0
01
2
il,
pr
5A
,1
Ethernet over Transport

ay
sd
ur
Th
on
No
of
L
ar
ou
An
by

Technology White Paper

d]
lle
tro
on
[c
ed
ad

by Steve Gorshe, Principal Engineer

lo
wn
Do

Issue No. 1: July, 2005

© PMC-Sierra, Inc.

Document No.: PMC-2050704, Issue 1 1

 Ethernet over Transport
White Paper

PM
Legal Information

35
7:
Copyright

:4
04
Copyright 2005 PMC-Sierra, Inc. All rights reserved.

0
01
The information in this document is proprietary and confidential to PMC-Sierra, Inc., and for its

2
customers’ internal use. In any event, no part of this document may be reproduced or

il,
redistributed in any form without the express written consent of PMC-Sierra, Inc.

pr
5A
PMC-2050704 (01)

,1
ay
Disclaimer

sd
ur
None of the information contained in this document constitutes an express or implied warranty

Th
by PMC-Sierra, Inc. as to the sufficiency, fitness or suitability for a particular purpose of any
on
such information or the fitness, or suitability for a particular purpose, merchantability,
performance, compatibility with other parts or systems, of any of the products of PMC-Sierra,
No

Inc., or any portion thereof, referred to in this document. PMC-Sierra, Inc. expressly disclaims
of

all representations and warranties of any kind regarding the contents or use of the information,
including, but not limited to, express and implied warranties of accuracy, completeness,
L
ar

merchantability, fitness for a particular use, or non-infringement.

ou

In no event will PMC-Sierra, Inc. be liable for any direct, indirect, special, incidental or
An

consequential damages, including, but not limited to, lost profits, lost business or lost data
by

resulting from any use of or reliance upon the information, whether or not PMC-Sierra, Inc. has
been advised of the possibility of such damage.
d]
lle
tro

Trademarks
on
[c

For a complete list of PMC-Sierra’s trademarks and registered trademarks, visit:

http://www.pmc-sierra.com/legal/
ed
ad
lo

Patents
wn
Do

Relevant patent grants may exist.

Document No.: PMC-2050704, Issue 1 2

 Ethernet over Transport
White Paper

PM
Abstract

35
A convergence of technology and applications has created an increased desire for Ethernet

7:
WAN connectivity. In many ways, Ethernet is an obvious technology choice. It simplifies

:4
enterprise network administration, and provides a ubiquitous, inexpensive infrastructure of

04
existing Ethernet interfaces on enterprise equipment. The development of VCAT and GFP

0
allows efficient transport of Ethernet frames through SONET/SDH networks. In addition,

01
Ethernet bridge and router technology requires less provisioning and administration than

2
technologies such as ATM. As some carriers begin a migration to using packet switching

il,
technology such as MPLS in their core networks rather than traditional circuit switching,

pr
Ethernet again looks like an excellent fit as an access technology.

5A
,1
This white paper describes how standards are developing to provide Ethernet WAN
connectivity and primarily focuses on the set of new standards for Ethernet transport over public

ay
networks developed by ITU-T Study Group 15 (SG15). It discusses the Ethernet services that

sd
are being considered over public WANs; transport network models that can be used to support

ur
Ethernet services; the Ethernet-based user network interfaces (UNIs) and network-to-network

Th
interfaces (NNIs) required for transport network equipment to carry Ethernet services;
on
Operations and Maintenance (OAM) capabilities; and protection and restoration technologies
that can be used to guarantee carrier-grade service reliability for Ethernet WAN services.
No
of

About PMC-Sierra
L
ar

PMC-Sierra™ is a leading provider of high-speed broadband communications and storage

ou

semiconductors and MIPS-Powered™ processors for Enterprise, Access, Metro Optical

An

Transport, Storage Area Networking and Wireless network equipment. The company offers
by

worldwide technical and sales support, including a network of offices throughout North
America, Europe and Asia. The company is publicly traded on the NASDAQ Stock Market
d]

under the PMCS symbol and is included in the S&P 500 Index.
lle
tro
on

About the Author

[c

Steve Gorshe, Ph.D. is a Principal Engineer in the Product Research Group and oversees ICs for
ed

SONET, optical transmission and access systems.

ad
lo

Currently, Steve is a senior member of the IEEE and co-editor for the IEEE Communications
wn

magazine’s Broadband Access Series. He is the chief editor for the ATIS OPTXS Committee
Do

(formerly T1X1), which is responsible for SONET and optical network interface standards. He
is a recent recipient of the Committee T1 Alvin Lai Outstanding Achievement Award for his
standards work and has been a technical editor for T1.105, T1.105.01, T1.105.02, and T1.105.07
within the SONET standard series as well as the ITU-T G.7041, G.8011.1, G.7043, and G.8040
recommendations. He has 26 patents issued or pending and several published papers.

Document No.: PMC-2050704, Issue 1 3

 Ethernet over Transport
White Paper

Revision History

PM
Issue Issue Date Details of Change

35
No.

7:
1 July 2005 Document created.

:4
04
0
01
2
il,
pr
5A
,1
ay
sd
ur
Th
on
No
of
L
ar
ou
An
by
d]
lle
tro
on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 4

 Ethernet over Transport
White Paper

PM
Table of Contents

35
Legal Information........................................................................................................................... 2

7:
Copyright................................................................................................................................. 2

:4
04
Disclaimer ............................................................................................................................... 2

0
Trademarks ............................................................................................................................. 2

01
Patents .................................................................................................................................... 2

2
il,
Abstract ......................................................................................................................................... 3

pr
About PMC-Sierra................................................................................................................... 3

5A
About the Author ..................................................................................................................... 3

,1
Revision History ...................................................................................................................... 4

ay
sd
1 Preface.................................................................................................................................... 8

ur
2 Why Ethernet Over the Public WAN? ..................................................................................... 9

Th
3 Service Types and Characteristics........................................................................................ 12
on
3.1 Ethernet Connection (EC) Defined ............................................................................. 12
No

3.2 Ethernet Connection (EC) Attributes........................................................................... 15

of

3.2.1 Network Connectivity .................................................................................. 15

L

3.2.2 Transfer Characteristics.............................................................................. 17

ar

3.2.3 Separation (Customer and Service Instance)............................................. 18

ou

3.2.4 Link Type..................................................................................................... 18

An

3.2.5 Connectivity Monitoring............................................................................... 18

by

3.2.6 Bandwidth Profile ........................................................................................ 18

d]

3.2.7 UNI List ....................................................................................................... 18

lle
tro

3.2.8 Preservation................................................................................................ 19
on

3.2.9 Survivability................................................................................................. 19
[c

3.3 Ethernet Private Line (EPL) Service ........................................................................... 19

ed

3.4 Ethernet Virtual Private Line (EVPL) Service.............................................................. 21

ad

3.5 Ethernet Private LAN (EPLAN) Service ...................................................................... 22

lo

3.6 Ethernet Virtual Private LAN (EVPLAN) Service ........................................................ 24

wn

4 Ethernet Client Interfaces ..................................................................................................... 25

Do

4.1 Multiplexed Access...................................................................................................... 25

4.2 VLAN Mapping ............................................................................................................ 26
4.3 Bundling ...................................................................................................................... 27
4.4 Bandwidth Profile ........................................................................................................ 27
4.5 Layer 2 Control Protocol Processing .......................................................................... 27

Document No.: PMC-2050704, Issue 1 5

 Ethernet over Transport
White Paper

4.6 Summary of UNI Service Attributes for Different Services.......................................... 27

PM
5 Protection and Restoration ................................................................................................... 29

35
5.1 Service Protection or Restoration Provided by the Transport Network ...................... 29

7:
:4
5.2 Service Restoration at Layer 2.................................................................................... 30

04
6 Conclusion ............................................................................................................................ 31

0
A Related Standards Activity .................................................................................................... 32

01
B Definitions ............................................................................................................................. 34

2
il,
C References............................................................................................................................ 35

pr
5A
,1
ay
sd
ur
Th
on
No
of
L
ar
ou
An
by
d]
lle
tro
on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 6

 Ethernet over Transport
White Paper

PM
List of Figures

35
Figure 1 Illustration of Ethernet Service Areas (ITU-T Rec. G.8011)........................................ 13

7:
Figure 2 Illustration of Private and Virtual Private Connections................................................ 14

:4
04
Figure 3 Network Connectivity Examples.................................................................................. 16

0
Figure 4 Network Portion of the Multipoint-to-Multipoint Topology (ITU-T Rec.

01
G.8011) .................................................................................................................... 17

2
Figure 5 EPL Service Illustration ............................................................................................... 19

il,
pr
Figure 6 EPLAN Illustrations ..................................................................................................... 22

5A
Figure 7 Service Multiplexing Example ..................................................................................... 26

,1
ay
sd
ur
List of Tables
Th
on
Table 1 Summary of the Types of Ethernet Services................................................................ 14
No

Table 2 Ethernet Connection Service Attributes (Derived from ITU-T Rec.

G.8011) .................................................................................................................... 15
of

Table 3 EPL Connection Characteristics (Derived from ITU-T Rec. G.8011.1)........................ 20

L

Table 4 EVPL Connection Characteristics ................................................................................ 21

ar
ou

Table 5 EPLAN Expected Connection Characteristics ............................................................. 23

An

Table 6 EVPLAN Expected Connection Characteristics ........................................................... 24

by

Table 7 UNI Service Attributes Common to All Services .......................................................... 25

d]

Table 8 Service-dependent UNI Service Attributes................................................................... 25

lle

Table 9 Summary of UNI Service Attributes for EPL and EVPL Services ................................ 28
tro

Table 10 Summary of Related Standards Activities.................................................................. 32

on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 7

 Ethernet over Transport
White Paper

PM
1 Preface

35
Due to a convergence of business requirements for higher data connectivity rates and flexible

7:
services, and the availability of new data transport technology, Ethernet has become the

:4
technology of choice for WAN connectivity both from the perspective of the enterprise and

04
from the perspective of the carrier (network operator).

0
01
This white paper examines the popularity of Ethernet over Transport and what factors

2
enterprises and carriers need to consider. Included in the discussion is an overview of Ethernet

il,
services that are being considered for delivery over public WANs as well as the attributes and

pr
characteristics that must be defined in order to provide these services. This discussion is based

5A
on the Ethernet transport work done for the ITU-T Study Group 15 (SG15) and its series of new

,1
standards. (See Appendix A.)

ay
This paper also examines the Ethernet-based user network interfaces (UNIs) and network-to-

sd
network interfaces (NNIs) that are required for transport network equipment carrying Ethernet

ur
services as well as Operations, Administration and Maintenance (OAM) capabilities. (Some

Th
OAM capability is already available in Ethernet services deployed over SONET/SDH (server
on
networks), but additional capabilities are required at the Ethernet Client layer.) The paper
concludes with a summary of some of the protection and restoration technologies that can be
No

used to guarantee carrier-grade service reliability for Ethernet WAN services.

of
L
ar
ou
An
by
d]
lle
tro
on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 8

 Ethernet over Transport
White Paper

PM
2 Why Ethernet Over the Public WAN?

35
On the enterprise side of the public WAN, Ethernet is the dominant technology. There are many

7:
reasons why there is growing interest in Ethernet WAN connection services:

:4
04
• At the enterprise, where it is the dominant technology, network administrators are already
familiar and comfortable with Ethernet.

0
01
• A number of applications, including voice and video, are already being encapsulated into

2
Ethernet and run over enterprise network LANs.

il,
pr
• More and more companies have a number of remote offices that need to exchange data with

5A
the headquarters office or with each other. There can be significant advantages to placing

,1
data on common servers that can be accessed by all sites.

ay
• The increased importance of the Internet for business applications has led to an increasing

sd
desire for incrementally higher WAN interface rates.

ur
• It is desirable to have a single Internet firewall at one site that is accessed on the enterprise

Th
network by all sites. on
Most enterprise WAN data access today uses Frame Relay connections at rates of fractional
No

DS1, full-rate DS1, fractional DS3, and full-rate DS3. In some cases, the data services use ATM
instead of Frame Relay either for the customer connection or as a method of transporting the
of

data through the core network. Frame Relay-based services suffer from a lack of scalability in
L

terms of both high-speed connections and ubiquitous multipoint networks. ATM suffers from
ar

being somewhat provisioning-intensive in large networks and bandwidth inefficient.

ou
An

At the other end of the ‘spectrum,’ some customers use WDM or dark fiber for their WAN or
MAN connections with native Gigabit Ethernet, 10 Gbit Ethernet, or Fibre Channel. However,
by

WDM equipment is expensive and not ubiquitously deployed, and dark fiber is not universally
d]

available, which limits the applications for these approaches. Another drawback of WDM and
lle

dark fiber applications is that unless they use the new G.709 Optical Transport Network
standard [1], there is no embedded overhead for carriers to monitor the quality of the connection
tro

or provide protection switching in order to guarantee their service level agreements (SLAs).
on
[c

Some larger customers use high-speed SONET OC-N / SDH STM-N connections, which
ed

typically terminate the Ethernet frames and re-encapsulate the data into PPP, and use Packet
over SONET/SDH (PoS) for transmission through a SONET/SDH pipe. On the carrier (network
ad

operator) side, the situation is somewhat complicated. In the wake of the telecom “bubble” burst
lo

in 2000, carriers face two clear drivers. First, they must deploy any new services on their
wn

existing SONET/SDH networks. Throughout the 1990s, carriers invested heavily in building
Do

SONET/SDH-based fiber optic networks, including developing the Operations, Administration,

Maintenance and Provisioning (OAM&P) systems to run them. The enormous capital
investment required to build an overlay network for data transport, be it native Ethernet or
DWDM-based, makes overlay networks unrealistic. Fortunately, SONET/SDH has proven
flexible enough to handle the challenge.

Document No.: PMC-2050704, Issue 1 9

 Ethernet over Transport
White Paper

Recent developments that extend the useful life of SONET/SDH include:

PM
• Virtual concatenation (VCAT) [2][3] to create more flexible data channel sizes.

35
•

7:
Link Capacity Adjustment Scheme (LCAS) [4] to increase the flexibility and functionality

:4
of VCAT.

04
• Generic Framing Procedure (GFP) [5][6] to encapsulate data frames for robust and

0
bandwidth-deterministic transport.

01
• Resilient Packet Ring (RPR) technology that provides a very flexible technology for data

2
il,
access onto SONET/SDH access and metro rings.

pr
A second driver for carriers is the desire to generate new, revenue-bearing services. With data

5A
traffic continuing to grow faster than voice, offering WAN connectivity with higher bandwidth

,1
and enhanced service capabilities appears to be a natural direction for new services. Equipment

ay
and device manufacturers, who are also interested in building new products, have also seen

sd
WAN connectivity as a natural direction.

ur
Ethernet is in many ways an obvious technology choice for WAN connectivity. The job of

Th
enterprise network administration is simplified if all their sites can be treated as part of the same
on
Ethernet network. In addition, Ethernet interfaces are relatively inexpensive and are ubiquitous
on enterprise equipment. The development of VCAT and GFP allows efficient transport of
No

Ethernet frames through SONET/SDH networks. In addition, Ethernet bridge and router
of

technology requires less provisioning and administration than technologies such as ATM. As
some carriers begin a migration to using packet switching technology such as MPLS in their
L

core networks rather than traditional circuit switching, Ethernet again looks like an excellent fit
ar
ou

as an access technology.
An

The IEEE, ITU-T Study Group 15 and 13, Metro Ethernet Forum (MEF), and Internet
by

Engineering Task Force are working on developing Ethernet transport standards. (Refer to
Appendix A.) This level of standards activity is a good indication of how many companies and
d]

organizations are interested in Ethernet WAN.

lle
tro

OAM is critical once Ethernet is extended beyond the customer premise, especially when
on

multiple transport service providers carry the traffic. In fact, although it is being actively
addressed by multiple standards bodies, including the ITU-T SG13, IEEE, and the MEF,
[c

Ethernet currently lacks some of the OAM capabilities that will be required to monitor and
ed

guarantee service level agreements (SLAs). In a multiple carrier environment, for example,
ad

OAM is crucial for determining the locations of problems and degradations when they occur.
lo

From a transport network provider standpoint, this OAM requirement is an area where
wn

SONET/SDH really shines. The OAM capabilities inherent in the SONET/SDH backbone allow
full monitoring and protection of the transmission facilities and transport path through the
Do

SONET/SDH network.

Document No.: PMC-2050704, Issue 1 10

 Ethernet over Transport
White Paper

Note that the relatively low cost of Ethernet enterprise equipment has created a customer

PM
expectation that Ethernet WAN interfaces should be less expensive than DS1/DS3 Frame Relay
interfaces. For the carriers, even if the Ethernet connectivity is provided through their

35
SONET/SDH backbone network, they still have to develop new OAM&P procedures and tools

7:
to provide the service. Therefore, even though customers and carriers agree that Ethernet (over

:4
04
SONET/SDH for the carriers) is the most attractive technology for high-speed WAN
connectivity, there is an inherent conflict between carriers needing to invest in equipment and

0
management system upgrades and customers demanding and expecting to pay less for Ethernet-

01
based services.

2
il,
pr
5A
,1
ay
sd
ur
Th
on
No
of
L
ar
ou
An
by
d]
lle
tro
on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 11

 Ethernet over Transport
White Paper

PM
3 Service Types and Characteristics

35
The description of Ethernet transport services varies depending on one’s vantage point. This

7:
white paper approaches Ethernet transport from the perspective of a transport network or

:4
service provider, rather than from a customer view of Ethernet transport services, and follows

04
the approach of the ITU-T G.8011 recommendation [9] in its discussion of the service types and

0
characteristics of Ethernet. (The G.8011.x series covers specific services within the framework

01
of G.8011.)

2
il,
One can say that the goal of the network provider is to make Ethernet service look like an

pr
extension of the customer’s Ethernet LAN. In order to provide this transparency, the network

5A
provider must take into account a number of items that are not necessarily directly visible to the

,1
customer. These items are presented in this section in terms of Ethernet connection attributes
and their associated parameters.

ay
sd
ur
3.1 Ethernet Connection (EC) Defined

Th
on
An Ethernet Virtual Connection (EVC), otherwise known as an Ethernet Connection (EC),
provides a connection between two or more customer UNIs such that the Ethernet frames
No

(service frames) associated with the EVC can only be transferred between its associated UNIs
of

and not to any others. Note that to be consistent with ITU-T G.8011, this white paper uses the
more generic term, EC, rather than EVC.
L
ar

Figure 1 illustrates an EC with its different reference points from the standpoint of both the
ou

Ethernet MAC layer network (ETH) and Ethernet physical layer network (ETY). Figure 1 also
An

illustrates the three different Ethernet service areas in a multi-carrier Ethernet connection:
by

• Access (UNI-C to UNI-N)

d]

• End-to-end/customer-to-customer (UNI-C to UNI-C)

lle

•
tro

Edge-to-edge/intra-carrier (UNI-N to UNI-N)

on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 12

 Ethernet over Transport
White Paper

Figure 1 Illustration of Ethernet Service Areas (ITU-T Rec. G.8011)

PM
35
demarc NNI demarc

UNI-N Transport
Transport Transport
Transport UNI-N

7:
UNI-C UNI-C
Operator
Operator Operator
Operator

:4
Customer Customer
AÕ
A ss
Õ B
BÕss
Õ

04
Network
Network Network
Network

0
UNI

01
Ethernet Connection
Attributes
Attributes

2
Access UNI-N to UNI-N Access

il,
UNI-C to UNI-C

pr
5A
ETH NNI
Attributes ETH

,1
ay
FD Operator FD Operator FD

sd
ur
FD
Th
Operator FD
on Operator FD
No

ETY ETY
of
L

Notes
ar

1. FD = Flow Domain
ou

2. Diagram reprinted with permission from ITU-T Recommendation G.8011.

An

From a customer’s perspective, the EC connectivity can be one of two types:

by

• Line connectivity (point-to-point)

d]
lle

• LAN connectivity (point-to-multipoint or multipoint-to-multipoint)

tro

From a transport network viewpoint, these line and LAN connections can either be provided:
on

•
[c

Through dedicated transport channels, including router bandwidth (private service)

ed

• Through a shared medium (virtual private service)

ad

The difference between a private line connection and a virtual private line connection is
lo

illustrated in Figure 2. The service type variations are summarized in Table 1.

wn
Do

Document No.: PMC-2050704, Issue 1 13

 Ethernet over Transport
White Paper

Figure 2 Illustration of Private and Virtual Private Connections

PM
35
Ethernet Ethernet

7:
PHY SONET/SDH/PDH/OTN PHY

:4
Customer A Customer A

04
Equipment Equipment
Carrier Network

0
Carrier Carrier

01
Equipment Equipment Customer B
Customer B

2
Equipment
Equipment

il,
pr
a) EPL for two customers, each with their own TDM channel

5A
,1
ay
sd
Ethernet Ethernet

ur
PHY PHY
SONET/SDH/PDH/OTH

Th
Customer A Customer A
Equipment on Equipment
Carrier Network
Carrier Carrier
No

Equipment Equipment Customer B

Customer B Equipment
of

Equipment
L

b) EVPL for two customers where they share a TDM channel for increased
ar

efficiency
ou
An

Table 1 Summary of the Types of Ethernet Services

by

Connectivity Resource Sharing Service Type

d]

Point-to-point Dedicated EPL (Ethernet Private Line)

lle

Shared EVPL (Ethernet Virtual Private Line)

tro

Multipoint Dedicated EPLAN (Ethernet Private LAN)

on

Shared EVPLAN (Ethernet Virtual Private LAN)

[c

Note
ed

1. The Metro Ethernet Forum (MEF) refers to EPL and EVPL as “E-Line services”, and EPLAN and
ad

EVPLAN as “E-LAN services”.

lo
wn
Do

Document No.: PMC-2050704, Issue 1 14

 Ethernet over Transport
White Paper

3.2 Ethernet Connection (EC) Attributes

PM
35
Various EC service attributes must be taken into account in a transport or service provider

7:
network. Table 2 lists these attributes.

:4
04
Table 2 Ethernet Connection Service Attributes (Derived from ITU-T Rec. G.8011)

0
EC Service Attribute Service Attribute Parameters and Values

01
2
Network connectivity Point-to-point, point-to-multipoint, multipoint-to-multipoint

il,
Transfer characteristics Address (deliver conditionally or unconditionally)

pr
Drop Precedence (drop randomly, drop conditionally, or not applicable)

5A
Class of Service

,1
Separation Customer Spatial or logical

ay
Service instance

sd
Link type Dedicated or shared

ur
Connectivity monitoring Sub-layer monitoring: On demand, proactive, none

Th
Inherent monitoring: Proactive
on
Bandwidth profile Specified
UNI list An arbitrary text string to uniquely identify the UNIs associated with the EC.
No

Preservation VLAN ID (yes or no)

of

Class of Service (yes or no)

L

Survivability None, or server-specific

ar
ou
An

3.2.1 Network Connectivity

by

One way in which Ethernet services can be characterized is by the type of desired customer
d]

connectivity. The types of connectivity are:

lle

• Point-to-point
tro

•
on

Point-to-multipoint
[c

• Multipoint-to-multipoint
ed

Figure 3 shows examples of these different connectivity types. Figure 3 (a) shows a basic point-
ad

to-point connection between customers through a transport network. Figure 3 (b) shows a
lo

popular point-to-multipoint topology known as hub-and-spoke. Figure 3 (c) through (e) show
wn

examples of various multipoint-to-multipoint topologies.

Do

Care must be taken to avoid confusing the customer connectivity (logical topology) with the
physical topology of the underlying network providing that connectivity. For example,
Figure 3 (b) and Figure 3 (d) use the same physical topology. The difference between a hub-
and-spoke and a star network is that a star network provides arbitrary multipoint-to-multipoint
connectivity between all the customer nodes while a hub-and-spoke network connects the hub
customer node to each of the spoke customer nodes (point-to-multipoint). Any connectivity
between spoke nodes would have to be provided by a router at the customer’s hub node.

Document No.: PMC-2050704, Issue 1 15

 Ethernet over Transport
White Paper

A logical hub-and-spoke network could be provided over the physical topology of any of the

PM
networks in Figure 3 (b) through (e). Figure 3 (c) through (e) illustrate common transport
network topologies. In reality, a transport network will often consist of a combination of star,

35
ring, and more arbitrary mesh sub-networks.

7:
:4
04
Figure 3 Network Connectivity Examples

0
2 01
TRANSPORT

il,
CE CE
NETWORK CE

pr
5A
a) Point-to-point CE

,1
TRANSPORT
CE

ay
NETWORK

sd
CE

ur
CE

Th
CE
on
b) Hub and spoke
No

TRANSPORT
CE CE
NETWORK
of
L

CE
CE CE
ar

c) Ring
ou

CE
An

TRANSPORT
CE
by

NETWORK

CE
d]
lle

CE CE
CE
tro

TRANSPORT d) Star
on

CE
NETWORK
[c
ed

CE
ad

CE
CE = Customer Edge
lo

e) Arbitrary
wn
Do

When discussing multipoint-to-multipoint connectivity, it is common to refer to the network

topological component that provides the desired forwarding of information between source and
destination UNIs as a flow domain (FD)1. In the example shown in Figure 4, if customers M and

1
A topological component describes a portion of a layer network in terms of the topological relationship
between the (flow) points.

Document No.: PMC-2050704, Issue 1 16

 Ethernet over Transport
White Paper

N are exchanging data, each is connected to a FD, with the flow domains being connected

PM
through an Ethernet link flow (LF) over the ABC network entity.

35
7:
Figure 4 Network Portion of the Multipoint-to-Multipoint Topology (ITU-T Rec. G.8011)

:4
04
ETH UNI

0
01
ETH FD

2
il,
XYZ PQR

pr
network entity network entity

5A
,1
ETH LF ETH LF

ay
ETH FD

sd
ETH FD ETH LF

ur
Th
on
ETH UNI
ETH UNI
No

ABC
Customer M Customer N
network entity
of

ABC, PQR, XYZ are server layer networks (can all be the same or different).
L

They may be CO-CS, CO-PS, CLPS

ar

Note
ou

1. Diagram reprinted with permission from ITU-T Recommendation G.8011.

An

A point-to-point connection can be characterized as either not having a flow domain or as

by

having a flow domain with only two flow points (that is, two end points of the network
d]

connection). The point-to-point connection is typically described as not having a flow domain
lle

since a flow domain implies a layer network with inherent switching/routing and other layer
tro

network capabilities. A flow domain with only two points is really the degenerate case of a
multipoint network and leaves open the potential of adding additional flow points (UNIs) to the
on

network.
[c
ed

3.2.2 Transfer Characteristics

ad

The transfer characteristics of a network relate to what frames are to be delivered to the
lo
wn

destination unconditionally, delivered conditionally, or are to be dropped. In the case of

Ethernet, the three parameters that determine the disposition of a frame are:
Do

• Address
• Drop Precedence (DP)
• Class of Service (CoS)

Document No.: PMC-2050704, Issue 1 17

 Ethernet over Transport
White Paper

For the address, a frame either can be delivered unconditionally, regardless of its destination

PM
address, or be delivered for only some destination addresses. The DP indicates the relative
priority of the frame if it encounters a congestion situation in which frame dropping must occur.

35
If dropping is based on the DP, frames are said to be dropped conditionally. Another option

7:
would be dropping randomly (that is, drop the overflow frames from a full queue). For some

:4
04
services, frames cannot be dropped and hence DP is not applicable. The CoS parameter, which
is based on the DP and indicates the frame’s class queuing, is not fully defined at this time.

0
01
2
3.2.3 Separation (Customer and Service Instance)

il,
pr
Separation refers to how the traffic of each customer or service instance is kept separate from

5A
the traffic of others. In the case of customer separation, the traffic from different customers is
separated. In the case of service instance separation, the different service instances are

,1
separated, even for the same customer. A spatial separation implies a circuit switched network

ay
(for example, a TDM network in which each customer has its own TDM channel or facility, or a

sd
virtual circuit such as in an ATM network). Logical separation implies that customer or service
instance traffic is separated at the packet level (that is, based on per-packet information such as

ur
address or tag values).

Th
on
3.2.4 Link Type
No

A link can either be dedicated to a single customer service instance or shared among multiple
of

service instances. For a dedicated link, a single customer service instance has a one-to-one
L

mapping to a set of one or more Ethernet links and the associated server layer trail (that is, a
ar

spatial separation from other service instances). As such, the service instance does not compete
ou

for bandwidth/resources (transport and switch fabric bandwidth) with other service instances,
An

and does not allow multiplexing on the access link (see Figure 2(a)). On the other hand, a
shared link allows more than one service instance to share that link, (that is, logical separation)
by

which means that the service instances can compete for the link resources (see Figure 2(b)).
d]
lle

3.2.5 Connectivity Monitoring

tro

Connectivity monitoring is the mechanism by which network nodes determine their ongoing
on

connectivity to their neighbor nodes in that layer network.

[c
ed

3.2.6 Bandwidth Profile

ad

A bandwidth profile specifies that parameters that a traffic flow must meet at a UNI or NNI.
lo

Policing of the bandwidth profile is typically done at the edge of the transport network.
wn
Do

3.2.7 UNI List

For the purposes of management and control, a service provider assigns an arbitrary string to
uniquely identify each UNI.

Document No.: PMC-2050704, Issue 1 18

 Ethernet over Transport
White Paper

3.2.8 Preservation

PM
Preservation refers to whether a customer’s Ethernet frame VLAN ID and/or CoS are preserved

35
through the transport network. If the value is preserved, it will have the same value at the egress

7:
UNI that it had at the ingress UNI of the transport network. In some circumstances, however, it

:4
may be necessary or desirable to change these values within the transport network. For example,

04
the service provider may perform a translation between the VLAN ID values that a customer

0
uses on the customer side of the network to a different set of VLAN IDs that are used within the

01
service provider network. Another example is that if a frame fails to meet the specified

2
bandwidth profile, the ingress node may choose to let it pass into the transport network but will

il,
set its DP value to a higher value so that it is prioritized for dropping if it encounters congestion.

pr
5A
3.2.9 Survivability

,1
ay
Survivability pertains to the ability of the network to continue to provide service under
situations in which a fault(s) exists in the network.

sd
ur
Th
3.3 Ethernet Private Line (EPL) Service on
EPL, as illustrated in Figure 5 and Figure 2, consists of point-to-point Ethernet connections
No

using reserved, dedicated bandwidth. With EPL, the transport network effectively looks like a
of

“piece of wire” from the Ethernet client perspective. From the transport network provider
standpoint, however, the transport network (server layer) provides the performance monitoring
L

and protection capabilities required for guaranteeing the service level agreement (SLA) with the
ar

customer.
ou
An

Figure 5 EPL Service Illustration

by
d]
lle

Ethernet Ethernet
SONET/SDH/PDH/OTH
tro

PHY (or ATM/MPLS CIR) PHY

on

Customer Carrier Network Customer

Equipment Carrier Carrier Equipment
[c

Equipment Equipment
ed
ad

The primary advantages of EPL are the simplicity of setting up a dedicated circuit, and the
lo

security for the traffic that is inherent when it is isolated in its own TDM channel2. Sharing
wn

bandwidth can lead to greater bandwidth efficiency in the transport network due to statistical
Do

multiplexing gains, however it is more difficult to administer since it requires additional effort
(for example, traffic engineering and monitoring) in order to guarantee the customer SLA.

2
It is also possible to provide EPL and EPLAN using constant rate ATM or MPLS virtual circuits instead
of TDM circuits.

Document No.: PMC-2050704, Issue 1 19

 Ethernet over Transport
White Paper

EPL service is described in ITU-T G.8011.1 [10]. The EPL connection characteristics are

PM
summarized in Table 3.

35
7:
Table 3 EPL Connection Characteristics (Derived from ITU-T Rec. G.8011.1)

:4
EC Service Attribute Service Attribute Parameters and Values

04
Network connectivity Point-to-point

0
01
Transfer characteristics Address - deliver unconditionally

2
Drop Precedence - not applicable

il,
Class of Service

pr
Separation Customer Spatial or logical (always connection oriented)

5A
Service instance

,1
Link type Dedicated

ay
Connectivity monitoring None, on-demand, or proactive

sd
Bandwidth profile Committed information rate (CIR) and committee burst size (CBS)

ur
UNI list An arbitrary text string to uniquely identify the UNIs associated with the EC.

Th
Preservation VLAN ID is preserved on
Class of Service is preserved
No

Survivability None, or server-specific

of

ITU-T G.8011.1 defines two types of EPL services:

L
ar

• Type 1 EPL, where the characteristic information (CI) transferred between the UNIs is the
ou

Ethernet MAC frames. The Ethernet preamble, start of frame delimiters, and inter-frame
An

characters are discarded, and the Ethernet MAC frames are then encapsulated (for example,
by

into GFP-F) and mapped into the transport channel.

•
d]

Type 2 EPL, which is only defined for 1 Gbit/s Ethernet, treats the 8B/10B line code
lle

information as the CI to be transferred between the UNIs. The data and control code
information from the Ethernet signal’s 8B/10B line code characters are translated into a
tro

more bandwidth-efficient 64B/65B block code, and multiple 64B/65B codes are then
on

mapped into a GFP frame (GFP-T).

[c

The primary advantages of Type 2 EPL are the preservation of control codes (primitive
ed

sequences of special line code characters) and lower mapping latency. While is possible to
ad

also define Type 2 EPL for 4B/5B encoded 100 Mbit/s Ethernet, there has been no formal
lo

request for this service so far.

wn
Do

Document No.: PMC-2050704, Issue 1 20

 Ethernet over Transport
White Paper

3.4 Ethernet Virtual Private Line (EVPL) Service

PM
35
EVPL is also a line service; however, the line can be derived from a flow domain. It allows the

7:
sharing of network resources among multiple customers or service instances in order to achieve

:4
efficient use of those resources. EVPL is illustrated in Figure 2(b).

04
In addition to increasing the efficient use of transport network resources, another potential

0
advantage of EVPL is the reduction of the number of UNIs required at the customer edge. This

01
is illustrated in Figure 7 in Section 4.1. For the customer edge node on the left to connect to four

2
other nodes would require four different UNIs and their associated ports. Service multiplexing

il,
pr
is the packet multiplexing of multiple ECs onto a single UNI.

5A
EVPL is specified in the ITU-T Recommendation G.8011.2. The EVPL connection

,1
characteristics are summarized in Table 4. For virtual connections, the separation is typically

ay
logical (that is, at the packet level). Due to the sharing of network resources, it is possible that

sd
frames will be dropped because of congestion. In addition, as discussed above, a service
provider may wish to perform VLAN ID translation at the boundaries of the transport network.

ur
Th
Table 4 EVPL Connection Characteristics on
EC Service Attribute Service Attribute Parameters and Values
No

Network connectivity Point-to-point

of

Transfer characteristics Address (deliver conditionally or unconditionally)

L

Drop Precedence (drop randomly or drop conditionally, depending on the

ar

Excess Information Rate (EIR) and Committed Information Rate (CIR)

ou

parameters)
An

Class of Service
Separation Customer Logical or spatial
by

Service instance
d]

Link type Shared or dedicated

lle

Connectivity monitoring Sub-layer monitoring: On demand and/or proactive

tro

Inherent monitoring: Proactive

on

Bandwidth profile Specified – Based on CIR and Committed Burst Size (CBS) (and in some
cases also on EIR and Excess Burst Size (EBS))
[c

UNI list An arbitrary text string to uniquely identify the UNIs associated with the EC.
ed

Preservation VLAN ID (yes or no)

ad

Class of Service (yes or no)

lo
wn

Survivability None, or server-specific

Do

Document No.: PMC-2050704, Issue 1 21

 Ethernet over Transport
White Paper

3.5 Ethernet Private LAN (EPLAN) Service

PM
35
An EPLAN provides LAN-type connectivity between multiple customer sites through dedicated

7:
channels. Figure 6 illustrates some of the different basic transport network topologies that can

:4
support this service. From the customer viewpoint, these topologies are equivalent (that is, the

04
carrier network architecture is transparent to the customer).

0
01
Figure 6 EPLAN Illustrations

2
il,
Ethernet

pr
PHY

5A
Customer
Ethernet

,1
Equipment
PHY

ay
Carrier Network
Ethernet Customer

sd
PHY Equipment

ur
Th
Customer
Equipment on
a) Mesh-type connectivity
No
of

Ethernet
PHY
L

Customer
ar

Equipment
ou

Customer
Carrier
An

Ethernet Equipment
Network
PHY
by

Customer
Equipment
d]
lle

b) Traffic hauled to a centralized switch point(s)

tro

Ethernet
on

PHY
[c

Customer
ed

Equipment
ad

Carrier Network
lo

Ethernet Customer
wn

PHY Equipment
Do

Customer
Equipment

c) Edge node serves as a bridge or router

Document No.: PMC-2050704, Issue 1 22

 Ethernet over Transport
White Paper

In Options 1 and 3, the carrier does the switching at the edge of the network. Option 3 does the

PM
switching at one end of the network rather than at each end. In Option 2, the traffic is brought to
a centralized switch (or a number of centralized switch points) in a star connection. Since the

35
switching is performed at Layer 2 in these examples, an MSPP can be used to implement

7:
Options 1 and 3.

:4
04
Open issues to be resolved for an EPLAN standard include:

0
01
• How do the customer and carrier specify the bandwidth requirements? For example, if the

2
traffic was evenly distributed among the different customer nodes, the bandwidth between

il,
nodes could be specified based on CIR. The more realistic scenario, however, is that

pr
multiple customer nodes will want to simultaneously communicate with a single node (for

5A
example, remote sites communicating with a headquarters office). A safe policy would be to

,1
reserve enough bandwidth for each node to simultaneously receive data at full rate from
each other node; however, this would too inefficient to be practical.

ay
•

sd
Closely related to the above issue, how much buffering must the carrier provide to handle

ur
congestion, and what will the discard policy be?

Th
• Is protection handled at Layer 1 (for example, SONET APS) or Layer 2?
on
Although EPLAN is still under study, its expected connection characteristics are summarized in
No

Table 5.
of

Table 5 EPLAN Expected Connection Characteristics

L
ar

EC Service Attribute Service Attribute Parameters and Values

ou

Network connectivity Multipoint-to-multipoint (and probably point-to-multipoint)

An

Transfer characteristics Address - deliver unconditionally

by

Drop Precedence – (for further study)

Class of Service
d]
lle

Separation Customer Spatial or logical (always connection oriented)

tro

Service instance
Link type Dedicated
on

Connectivity monitoring None, on-demand, or proactive

[c

Bandwidth profile Committed information rate (CIR) and committed burst size (CBS)
ed

UNI list An arbitrary text string to uniquely identify the UNIs associated with the EC.
ad

Preservation VLAN ID is preserved

lo
wn

Class of Service is preserved

Survivability None, or server-specific
Do

Document No.: PMC-2050704, Issue 1 23

 Ethernet over Transport
White Paper

3.6 Ethernet Virtual Private LAN (EVPLAN) Service

PM
35
EVPLAN is a combination of EVPL and EPLAN. The transport channel bandwidth is shared

7:
among different customers, as are the routers in the carrier network. Ultimately, the sharing of

:4
bandwidth in the transmission channels and switch fabrics gives EVPLAN the potential for very

04
cost-effective carrier network resource utilization. Clearly, however, EVPLAN is the most
complicated network architecture to administer.

0
01
The open issues regarding EVPLAN transport architectures include all of those already

2
discussed for EVPL and EPLAN; although, the magnitude of some of these issues is greatly

il,
pr
increased for EVPLAN, which in turn restricts some of the potential solution space. For

5A
example, the tagging mechanism to differentiate the data from different customers, and the
different data flows within each customer data stream, must have an adequately large address

,1
space. (For example, the 4K-address space of VLAN tags makes them impractical for large

ay
EVPLANs. Also, their applicability to only Ethernet frames further lessens their appeal for a

sd
generic data network.)

ur
Although EPLAN is still under study, its expected connection characteristics are summarized in

Th
Table 11-7. on
No

Table 6 EVPLAN Expected Connection Characteristics

of

EC Service Attribute Service Attribute Parameters and Values

L

Network connectivity Multipoint-to-multipoint (and probably point-to-multipoint)

ar

Transfer characteristics Address (deliver conditionally or unconditionally)

ou

Drop Precedence (drop randomly, drop conditionally, or not applicable)

An

Class of Service
by

Separation Customer Logical

Service instance
d]
lle

Link type Shared

tro

Connectivity monitoring None, on-demand, or proactive

Bandwidth profile Specified
on

UNI list An arbitrary text string to uniquely identify the UNIs associated with the EC
[c

Preservation VLAN ID (yes or no)

ed

Class of Service (yes or no)

ad

Survivability None, or server-specific

lo
wn
Do

Document No.: PMC-2050704, Issue 1 24

 Ethernet over Transport
White Paper

PM
4 Ethernet Client Interfaces

35
The client interface (that is, the UNI) for Ethernet services will typically be an Ethernet physical

7:
interface. In the past, the UNI for WAN data connections was typically based on telecom signals

:4
(for example, DS1, DS3, fractional-DS1, etc.), which required either special customer

04
equipment (for example, a T1 multiplexer) or special WAN port cards on customer routers.

0
01
Being able to use an Ethernet interface is advantageous for enterprise customers. Ethernet

2
interfaces are typically less expensive than telecom WAN interfaces, especially for higher bit

il,
rates, and are supported by relatively inexpensive Ethernet LAN routers. Using an Ethernet

pr
interface also allows enterprise network administrators to keep their OAM in the Ethernet

5A
domain and allows carriers to handle the telecom signal domain.

,1
The Ethernet UNI service attributes that are common for all services are shown in Table 7 and

ay
the attributes that are service dependent are shown in Table 8.

sd
ur
Table 7 UNI Service Attributes Common to All Services
Layer UNI Service Attribute
Th
Service Attribute Parameters and Values
on
ETH MAC service IEEE 802.3 frame format
No

UNI ID Arbitrary text string to identify each UNI instance

of

UNI EC ID Arbitrary text string to identify each EC instance

L

ETY PHY speed 10 Mbit/s, 100 Mbit/s, 1 Gbit/s, or 10 Gbit/s

ar

PHY medium IEEE 802.3 Physical interface

ou
An

Table 8 Service-dependent UNI Service Attributes

by

Layer UNI Service Attribute Service Attribute Parameters and Values

ETH Multiplexed access Yes, no
d]
lle

VLAN mapping Specify

tro

Bundling Yes, no, all-to-one

Bandwidth profile For further study for most services
on

Layer 2 control Block, process, or pass per protocol on ingress

[c

protocol processing Generate, or none per protocol on egress

ed

ETY PHY mode Full duplex, half duplex, or auto-negotiation

ad
lo
wn

The UNI service attributes common to all services are reasonably self-explanatory so are not
discussed in this paper. The service-dependent attributes are explained as follows.
Do

4.1 Multiplexed Access

This aspect of the UNI relates to whether a customer edge node has an individual UNI
associated with each of the far-end UNIs to which it is connected, or whether a UNI is shared
for the connections to multiple other customer UNIs. These cases are illustrated in Figure 7.

Document No.: PMC-2050704, Issue 1 25

 Ethernet over Transport
White Paper

Figure 7 Service Multiplexing Example

PM
35
CE

7:
4 x UNI

:4
04
TRANSPORT CE

0
CE

01
NETWORK

2
CE

il,
pr
5A
CE

,1
a) Multiple point-to-point EPL

ay
(one EVC per UNI)

sd
ur
Th
CE
UNI
on
No

TRANSPORT CE
of

CE
NETWORK
L
ar

CE
ou

CE
An
by

b) Service multiplexed UNI

(e.g., for multiple EVPL)
d]
lle
tro

4.2 VLAN Mapping

on
[c

Ethernet (per IEEE 802.1Q) allows the insertion of tags into Ethernet MAC frames in order to
ed

create virtual LANs (VLANs). When a customer desires to preserve this VLAN segregation of
ad

traffic through the WAN, the carrier may simply preserve the entire MAC frame, including the
VLAN tag.
lo
wn

It is possible that both the customer and service provider desire to use VLAN technology. If the
Do

service provider also wishes to use VLAN technology, then it must either must insert a second
(“stacked”) VLAN tag into the MAC frame, or perform a translation of the customer VLAN tag
at the ingress in order to conform to the service provider’s VLAN tag assignments, and then
restore the customer VLAN value at the egress.

Document No.: PMC-2050704, Issue 1 26

 Ethernet over Transport
White Paper

4.3 Bundling

PM
35
Bundling refers to whether multiple customer VLAN IDs can be mapped into a single EC at a

7:
UNI. The case where all VLAN IDs are mapped to a single EC is called all-to-one bundling. It

:4
should be noted that all-to-one bundling and multiplexed access are mutually exclusive.

04
Multiplexed access refers to the multiplexing of multiple ECs into a UNI. Mapping all VLAN
IDs into a single EC means that there is a single EC at that UNI rather than multiple ECs.

0
01
2
4.4 Bandwidth Profile

il,
pr
5A
The bandwidth profile refers to the characteristics of the traffic that a customer presents to the
network at the UNI. The parameters include such things as guaranteed committed information

,1
rate (CIR), peak information rate (PIR), burst sizes, and what is done with excessive traffic.

ay
sd
ur
4.5 Layer 2 Control Protocol Processing

Th
Layer 2 Control Protocols are used by enterprise network bridges for a variety of functions.
on
Depending on the protocol application and the WAN service, these protocols can either be
No

passed transparently through the WAN, processed (with the network provider equipment acting
as a peer to the customer equipment), or discarded at the UNI.
of
L
ar

4.6 Summary of UNI Service Attributes for Different Services

ou
An

The UNI service attributes are currently only defined for EPL service (ITU-T G.8011.1). These
attributes are summarized in Table 9. EVPL and EVPLAN (especially EVPLAN) will typically
by

make use of bundling and multiplexed access and have more complex bandwidth profiles.
d]
lle
tro
on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 27

 Ethernet over Transport
White Paper

Table 9 Summary of UNI Service Attributes for EPL and EVPL Services

PM
Layer UNI Service Attribute Service Attribute Parameters and Values

35
EPL

7:
ETH Multiplexed access No

:4
04
VLAN mapping No
Bundling All-to-one

0
01
Bandwidth profile CIR, Committed Burst Size (CBS)

2
Layer 2 control protocol All are passed except PAUSE frames, which are discarded.

il,
processing (The network equipment providing the UNI-N may generate

pr
PAUSE frames.)

5A
ETY PHY mode Full duplex
EVPL

,1
ETH Multiplexed access Yes or No

ay
sd
VLAN mapping Yes or No
Bundling Yes or All-to-one

ur
Th
Bandwidth profile For further study
Layer 2 control protocol Specified in G.8011.2
on
processing
No

ETY PHY mode Full duplex

of
L
ar
ou
An
by
d]
lle
tro
on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 28

 Ethernet over Transport
White Paper

PM
5 Protection and Restoration

35
For WAN transport, service protection is typically provided by the underlying transport

7:
network. However, service restoration can also be provided only at the Ethernet layer using

:4
Ethernet protocols. Both approaches are summarized briefly here.

04
0
01
5.1 Service Protection or Restoration Provided by the Transport

2
Network

il,
pr
5A
Transport networks have traditionally been engineered for ultra-high service availability in
order to ensure reliable communications for emergency voice traffic. The objective is for a fault

,1
to be detected and the service restored through a protection switching action within 60 ms

ay
(10 ms for the detection and 50 ms to complete the switch). A protection switch action is

sd
defined as the routing of the traffic from the failed facility or equipment to backup facilities or
equipment that has been reserved in advance3. In most cases, the protection channels are

ur
Th
permanently reserved, with their bandwidth either being unused during fault-free conditions, or
carrying low-priority traffic that can be dropped if the channel is required for protection. In the
on
case of TDM transport systems such as SONET/SDH, the protection switch is between TDM
No

channels or fibers [15]. In the case of ATM, the protection switch is between virtual circuits
[16].
of
L

The Link Capacity Adjustment Scheme (LCAS) provides an alternative approach for restoring
ar

data services. For constant bit rate services such as voice, it is necessary to have protection
ou

bandwidth that is at least equal to the service bandwidth. In the case of packetized data,
however, it is possible in many cases to maintain the service connection at a lower data rate in
An

the event of a network problem. LCAS provides this capability through its control of virtually
by

concatenated SONET/SDH, asynchronous/PDH, or OTH channels.

d]

Virtual concatenation is the construction of a larger channel through the combining of multiple
lle

smaller member channels. The data is then interleaved onto the constituent member channels in
tro

a byte-by-byte round-robin basis. The individual members can take different routes through the
on

transport network with the network element (NE) that terminates the virtually concatenated
[c

channel providing the buffering to compensate for the differences in delay that result from the
different routes. 4
ed
ad
lo
wn
Do

3
In mesh networks that are constructed with digital cross connect systems (DCS), it is possible to have
the DCSs restore the traffic by communicating among each other to determine the protection path through
the network in response to a fault. While this approach typically allows the network operator to reserve
much less overall network bandwidth for protection, it can be difficult to meet the 50 ms switch time.
4
Virtual concatenation is described in S. Gorshe, “A Tutorial on SONET/SDH,” PMC-Sierra white paper
PMC-2030895.

Document No.: PMC-2050704, Issue 1 29

 Ethernet over Transport
White Paper

In the event that a subset of the members fail, the LCAS provides the signaling mechanism

PM
between the virtually concatenated channel’s source and sink to allow the source to place the
traffic onto only those members that have not failed. This allows for a very powerful new

35
paradigm for network operators since, for services that can tolerate the reduced data rate during

7:
faulted conditions, the operator can now provide very fast service restoration without having to

:4
04
reserve dedicated protection channels.

0
01
5.2 Service Restoration at Layer 2

2
il,
pr
When constructing a complex Ethernet network, it is important that only a single switching path

5A
exist between any pair of nodes. Otherwise, loops would exist that cause instability in
forwarding tables and would cause broadcast data to be unnecessarily multiplied (that is,

,1
broadcast storms).

ay
sd
The Ethernet solution to this issue is the spanning tree protocol (STP). The STP sends Layer 2
control protocol messages between the Ethernet nodes in order to establish an overlaid logical

ur
tree structure on the network. Messages are periodically sent between adjacent nodes to confirm

Th
that no changes have occurred to the network connectivity. When a fault occurs, the node
on
detecting the failure (that is, the change in network connectivity) will initiate a new spanning
tree construction. The network is then unavailable for the 30 to 60 seconds that it can take for
No

the STP to resolve. A new rapid STP (RSTP) protocol has been developed, but it still takes
of

seconds to resolve.
L

While this is a very powerful and flexible service restoration tool, there are several issues when
ar

it is applied to Ethernet WAN services. Of course, the larger the network in terms of number of
ou

nodes and geographical reach, the slower the STP resolution. Another potential issue occurs if
An

the network operator uses Ethernet routing technology within its network. Here, conflicts
by

between customer and network operator STPs must be avoided. Another issue is the interaction
of the 50 ms protection switching (for example, SONET/SDH) with the STP. If the Ethernet
d]

node and the transport network node both detect the fault, it would cause unnecessary extended
lle

network unavailability if the STP were initiated for a fault that will be quickly protected by the
tro

SONET protection switch. It is desirable, then for the Ethernet node to wait at least 50 ms to see
on

if the problem clears before it initiates the STP.

[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 30

 Ethernet over Transport
White Paper

PM
6 Conclusion

35
A convergence of technology and applications has increased the importance and value of wide-

7:
area Ethernet data transport services. This white paper has introduced some of the new

:4
technology and standards in development that will enable carriers to provide these services.

04
This includes a discussion of Ethernet’s connection services, client interfaces, and protection

0
and restoration abilities.

01
2
What makes the development of Ethernet transport service attractive is its evolutionary

il,
approach. It builds on the customers’ capital investment in Ethernet technology, and the

pr
transport providers’ existing SONET/SDH backbone networks and OAM procedures. All of the

5A
pieces are currently in place for offering EPL services. The tools and standards to provide the

,1
more complicated ELAN, EVPL, and EVPLAN services are currently being developed by the
various standards bodies.

ay
sd
While some proprietary data transport solutions exist, carriers require standards-based solutions,

ur
which Ethernet data transport provides, for any significant deployment of new services. The use

Th
of standards helps guarantee that the solution will be available from multiple vendors, will be
on
stable and supported for many years, and ideally will be less expensive due to economies of
scale. While each carrier will probably want to offer variations on the basic service types in
No

order to differentiate themselves from their competitors, the services discussed in this paper
provide the framework from which they can build.
of
L
ar
ou
An
by
d]
lle
tro
on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 31

 Ethernet over Transport
White Paper

PM
A Related Standards Activity

35
The information in this white paper primarily focuses on the output of the Ethernet transport

7:
work in ITU-T Study Group 15 (SG15) and its series of new standards. SG15 is the ITU-T body

:4
responsible, among other things, for standards related to public transport networks.

04
0
The current level of standards activity is a good indication of how many companies and

01
organizations see Ethernet WAN as the next key step both for Ethernet and for the public

2
transport network providers (that is, carriers). The major standards activities and their status are

il,
summarized in Table 10.

pr
5A
Table 10 Summary of Related Standards Activities

,1
Organization Activities Status

ay
sd
IEEE

ur
802.3ae 10 Gbit Ethernet, which includes a WAN PHY interface to simplify Approved
interfacing to a SONET/SDH or G.709 OTN network

Th
802.17 Resilient Packet Rings: Working on a ring-based network for
on Approved
access and metro applications
802.3ah Ethernet in the First Mile, where work includes OAM aspects for Approved
No

(EFM) Ethernet Links (especially access links)

of

802.1 ad Provider Bridge specification – This is the Q-in-Q standard. In Progress

L

802.1ag Connectivity Fault Management, or Ethernet Service OAM In Progress

ar

802.1ae MAC Security (MacSec), including authentication, authorization In progress

ou

and encryption
An

ITU-T SG15
(With input from ANSI T1X1)
by

G.8011.1 Ethernet Private line service Approved

(Q11)
d]
lle

G.8011.2 Ethernet Virtual Private line service Approved

(Q11)
tro

G.8012 Ethernet UNI and Ethernet Transport NNI Approved

on

(Q11)
[c

G.8010 Ethernet Layer Network Architecture, which is largely to translate Approved

ed

(Q12) the IEEE 802 network material into ITU-T transport network
terminology and models
ad

G.8011 Ethernet over Transport – Ethernet Service Characteristics Approved

lo

(Q11)
wn

G.esm Ethernet over Transport – Ethernet Service Multiplexing, which In Progress

Do

(Q12) covers the multiplexing protocol(s) required to implement EVPL

and EVPLAN
G.8021[7] Characteristics of Ethernet transport network equipment functional Approved
(Q9) blocks 2004 (1st
phase)
Y.ethps Ethernet protection switching In progress
(Q3)
Q2 Studying Ethernet OAM aspects relating to access In progress

Document No.: PMC-2050704, Issue 1 32

 Ethernet over Transport
White Paper

Organization Activities Status

PM
ITU-T SG13

35
Y.1730 Requirements for OAM functions in Ethernet-based networks and Approved

7:
Ethernet services

:4
Y.ethoam End-to-end and edge-to-edge aspects of Ethernet OAM including In progress

04
(Q3) PM

0
Metro Ethernet Forum (MEF)

01
The MEF is studying various aspects of Ethernet MANs, including Ethernet architecture, service model,

2
service definition, traffic management, UNI and NNI definition and OAM. The MEF work is covering all

il,
possible OAM flows, such as end-to-end, edge-to-edge, access, inter-provider, intra-provider, etc.

pr
MEF1 Ethernet Services Model, Phase 1 Approved

5A
MEF2 Requirements and Framework for Ethernet Service Protection in Approved

,1
Metro Ethernet Networks

ay
MEF3 Circuit Emulation Service Definitions, Framework and Approved
Requirements in Metro Ethernet Networks

sd
MEF4 Metro Ethernet Network Architecture Framework - Part 1: Generic Approved

ur
Framework

Th
MEF5 Traffic Management Specification: Phase I
on Approved
UNI Type 1 Specification of UNI, data-plane aspects In progress
No

UNI Type 2 Specification of UNI, control-plane aspects (ELMI) In progress

EMS-NMS MIBS for Ethernet and network management In progress
of

MEF Architecture Specifies functional elements of Ethernet trail, such as adaptation, In progress
L

part 2 conditioning, etc.

ar

CES PDH Implementation agreement of PDH CES over Ethernet (includes In progress
ou

both AAL1 and Raw method)

An

Internet Engineering Task Force (IETF)

PWE3 WG Working on defining an Ethernet transport over IP/MPLS using In progress
by

Martini drafts (this is mainly EVPL service using UDP, L2TP or

d]

MPLS as multiplexing layer)

lle

PPVPN WG Requirements for Virtual Private LAN Services (VPLS) In progress

tro

L2VPN WG Working on framework and service requirements of Ethernet-based In progress

VPN, and defining EVPLAN service using IP/MPLS
on
[c
ed

Note that each standards organization has its own areas of expertise. The majority of the
standards that will be required for the public transport network are being developed in the Q12
ad

and Q11 groups of ITU-T SG15. This work was partitioned not only logically by topic, but also
lo

in a manner that allowed for the earliest possible approval of useful standards/
wn

recommendations. The initial set of standards was approved in mid-2004 (see Table 10).
Do

ITU-T SG15 has established liaison contact with the other standards organizations and forums
where their input is required or desired. For example, the G.ethsrv work is expected to use a
considerable amount of input from the MEF regarding the definition of services.

Document No.: PMC-2050704, Issue 1 33

 Ethernet over Transport
White Paper

PM
B Definitions

35
The source of these definitions is the G.809 ITU-T recommendation.

7:
:4
Term Definition

04
Access group A group of co-located "flow termination" functions that are attached to the
same "flow domain" or “flow point pool link".

0
01
Characteristic Information A signal with a specific format, which is transferred on "flows". The specific

2
(CI) formats are defined in technology-specific standards.

il,
Flow An aggregation of one or more traffic units with an element of common

pr
routing.

5A
Flow domain A topological component used to effect forwarding of specific characteristic
information.

,1
Flow point A "reference point" that represents a point of transfer for traffic units

ay
between topological components.

sd
Flow point pool A group of co-located flow points that have a common routing.

ur
Flow point pool link A "topological component" which describes a fixed relationship between a

Th
"flow domain" or "access group" and another "flow domain" or "access
group". on
Flow termination A "transport processing function". There are two types of flow termination, a
No

flow termination sink and a flow termination source.

Link flow A "transport entity" that transfers information between "ports" across a flow
of

point pool link.

L

Topological component An architectural component, used to describe the transport network in terms
ar

of the topological relationships between sets of points within the same layer
ou

network.
An
by
d]
lle
tro
on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 34

 Ethernet over Transport
White Paper

PM
C References

35
[1] ITU-T Recommendation G.709 (2001), Interfaces for the optical transport network

7:
(OTN).

:4
04
[2] ITU-T Recommendation G.707 (2003), Network node interface for the Synchronous

0
Digital Hierarchy (SDH).

01
2
[3] ITU-T Recommendation G.7043/Y.1343 (2004), Virtual concatenation of Plesiochronous

il,
Digital Hierarchy (PDH) signals.

pr
5A
[4] ITU-T Recommendation G.7042 (2004), Link Capacity Adjustment Scheme (LCAS) for

,1
Virtual Concatenated signals.

ay
[5] ITU-T Recommendation G.7041/Y.1303 (2003) - The Generic Framing Procedure (GFP).

sd
ur
[6] ITU-T Recommendation G.8040 (2004), GFP frame mapping into Plesiochronous Digital

Th
Hierarchy (PDH).
on
[7] ITU-T Recommendation G.8021/Y.1341 (2004), Characteristics of Ethernet transport
No

network equipment functional blocks.

of

[8] ITU-T Recommendation G.809 (2003), Functional architecture of connectionless layer

L

networks.
ar
ou

[9] ITU-T Recommendation G.8011/Y.1307 (2004), Ethernet Services Framework.

An

[10] ITU-T Recommendation G.8011.1/Y.1307.1 (2004) Ethernet Private Line Service.

by

[11] ITU-T Recommendation G.8011.2/Y.1307.2 (2005) Ethernet Virtual Private Line Service
d]
lle

[12] ITU-T Recommendation G.8012/Y.1308 (2004), Ethernet UNI and Ethernet NNI.
tro
on

[13] ITU-T Recommendation G.805 (2001), Generic functional architecture of transport

[c

networks.
ed

[14] ITU-T Recommendation G.8010/Y.1306 (2004), Ethernet Layer Network Architecture.

ad
lo

[15] ITU-T Recommendation G.808.1 (2003), Generic Protection Switching – Linear Trail and
wn

Subnetwork Protection.
Do

[16] ITU-T Recommendation I.630 (2000) ATM Protection Switching.

Document No.: PMC-2050704, Issue 1 35

 Ethernet over Transport
White Paper

PM
Contacting PMC-Sierra

35
PMC-Sierra

7:
8555 Baxter Place

:4
Burnaby, BC

04
Canada V5A 4V7

0
01
Tel: +1 (604) 415-6000

2
Fax: +1 (604) 415-6200

il,
pr
Document Information: document@pmc-sierra.com

5A
Corporate Information: info@pmc-sierra.com

,1
Technical Support: apps@pmc-sierra.com
Web Site: http://www.pmc-sierra.com

ay
sd
ur
Th
on
No
of
L
ar
ou
An
by
d]
lle
tro
on
[c
ed
ad
lo
wn
Do

Document No.: PMC-2050704, Issue 1 36