Carrier Ethernet Basics

Educational Series 1 2 3 4 5 6

Service
Turn-Up
Service
Turn-Up

AUTHORS
BRUNO GIGUÈRE, Advisor–CTO Office, EXFO
SYLVAIN CORNAY, Marketing Manager, EXFO
HAMMADOUN DICKO, Product Specialist, EXFO
THIERNO DIALLO, Product Specialist, EXFO
SOPHIE LEGAULT, Product Line Manager, EXFO
SUE JUDGE, Consultant

EXFO Inc.
August, 2011
3. WHAT IS SERVICE TURN-UP
FOR CARRIER ETHERNET? . . . . . . . . . . . . . . . . . . . . . . . . . 3– 4

3.1 Ethernet Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3– 5

3.1.1 Business Services . . . . . . . . . . . . . . . . . . . . . . . . . 3– 6
3.1.2 Mobile Backhaul Services . . . . . . . . . . . . . . . . . . . . . 3– 7
3.2 Test Architectures and Modes . . . . . . . . . . . . . . . . . . . . . . . 3– 8
3.2.1 Test Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 3– 8
3.2.1.1 Distributed Test Architecture . . . . . . . . . . . . . . . . . . . .3– 8
3.2.1.2 Centralized Test Architecture . . . . . . . . . . . . . . . . . . . 3– 9
3.2.1.3 Testing Using Network Interface Devices . . . . . . . . . . . . 3– 9
3.2.1.4 Performance End-Point Unit . . . . . . . . . . . . . . . . . . . 3– 10
3.2.2 Test Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3– 10
3.2.2.1 Testing to a Loopback Function . . . . . . . . . . . . . . . . . 3– 10
3.2.2.2 Testing a Dual Test-Set Scenario . . . . . . . . . . . . . . . . . 3– 10

3.3 Service Turn-Up Test Methodologies . . . . . . . . . . . . . . . . . . 3– 12

3.3.1 ITU-T Y.1564 Ethernet Service Activation Test Methodology 3– 12
3.3.1.1 ITU-T Y.1564 Service Configuration Test . . . . . . . . . . . . 3– 12
3.3.1.2 ITU-T Y.1564 Service Performance Test . . . . . . . . . . . . . 3– 14

3.4 Birth Certificate 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3– 15

3.5 Sample Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3– 16
3.5.1 Business Ethernet Services . . . . . . . . . . . . . . . . . . 3– 16
3.5.1.1 Service Configuration Test . . . . . . . . . . . . . . . . . . . . 3– 16
3.5.1.2 Service Performance test . . . . . . . . . . . . . . . . . . . . .3– 17

3.5.2 Mobile Backhaul Services . . . . . . . . . . . . . . . . . . . . 3– 17

3.5.3 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . 3– 18

Also coming soon to the Carrier Ethernet Basic Educational Series, modules that will focus on the
following aspects of Carrier Ethernet, including service monitoring and troubleshooting.

3– 3
3 WHAT IS SERVICE TURN-UP
FOR CARRIER ETHERNET?

Four phases are essential to building, characterizing and evaluating a Carrier Ethernet
network: construction, service turn-up/burn-in, monitoring and troubleshooting. The service
turn-up and burn-in phase is critical as it proves that the circuit can deliver the performance
as specified in the service level agreement (SLA), which is the last phase for service
providers to qualify the network before delivery to the customer.

• 24 x 7 measurements of key performance

indicators (KPIs) for deployed services
• Metrics gathered via OAM-compliant
Ethernet devices (IEEE 802.1ag and
• Characterize physical ITU-T Y.1731)
connections
• Alerts/alarms to report service
• Validate link degradations and initiate the service
performance troubleshooting process
• Ensure clean • Aggregation and analysis of KPIs for
connections historical and near real-time reports

CONSTRUCTION SERVICE TURN-UP

AND BURN-IN
SERVICE
SERVICE
MONITORING

• Perform wire-speed service validation

MONITORING
4 SERVICE
TROUBLESHOOTING

• Service degradation
through EtherSAM testing troubleshooting
(ITU-T Y.156sam) or RFC 2544 triggered by performance
monitoring system
• Validate proper service
configuration/provisioning • Tests from the MSC to the
(i.e., VLAN and class of service) tower, leveraging Ethernet
OAM standards to test and
• Defi ne a consistent procedure
interrogate remote devices
to activate services quickly and efficiently
• Dispatch technician with
• Archive test results for reporting and
portable device to perform
future referencing purposes
additional troubleshooting

Figure 3.1 The service lifecycle assessment

The turn-up and burn-in cycle is a dual-stage process where carriers and service providers
test and validate their service configuration and the provisioning of the different classes of
service (CoS) in the network. The key aspect of the service turn-up phase is validating
that the network elements are properly configured and that the network is able to support
the different services while ensuring their performance.

The burn-in phase focuses on a longer test period, typically 24 to 72 hours, with the goal of
evaluating how the network reacts when all the services are forwarded at the same time and
at their maximum committed rate. During these two phases, the key performance indicators
(KPIs) are monitored to ensure that performance is met at all times.

The following sections focus on service turn-up. We will review the main KPIs related
to business and mobile backhaul services and present the different test architectures,
modes and methodologies available to validate services.

3– 4
 Service Turn-Up

3.1 Ethernet Services

The main Metro Ethernet Forum (MEF) technical specifications covering Ethernet
services are:

• MEF 10.2: The Ethernet Service Attributes (Phase 2) defines KPI service
attributes

• MEF 23: Carrier Ethernet Class of Service Implementation Agreement (Phase 1)

provides a CoS framework that can be used by service providers to define the
performance expectations of different services.

When combined, these MEF specifications provide the definition required to

assess the performance of Ethernet services. However, guidance on KPIs is
currently limited, especially for Ethernet services. As the MEF is working to
address this issue, service providers have to rely on best practices or turn to
other recommendations in the meantime, such as the ITU-T Y.1541 (Network
Performance Objectives for IP-Based Services), published in February 2006 to
provide guidance on KPIs for different services.

CoS EVC FD FDV FLR Ingress UNI PCP / PHB (DSCP)CoS PCP / PHB Example
Label Type Bandwidth and Color Identifiers 1 (DSCP) Applications
Profile CoS-only
Color Identifiers 1
Constraints 3 Green Color
Yellow 2
w/DEI
Pt-Pt AFD AFDV AFLR CIR>0 VoIP and
5 / EF N/S in
H EIR3≥04 5 / EF (46) backhaul
Multi-pt AFD AFDV AFLR (46) phase 1
CF=0 control
Near real-
Pt-Pt B FD B FDV B FLR
CIR>0 3 / AF31 2 / AF32 (28) 2-3 / AF31-33 time or
M
EIR3≥0 (26) or AF33 (30) (26, 28, 30) critical
Multi-pt B FD B FDV B FLR data apps
Pt-Pt CFD CFDV CFLR 0 / AF12 (12), 0-1 / AF11-13
CIR3≥0 1 / AF11 TBD in future
L AF13 (14) or (10, 12, 14)
Multi-pt CFD CFDV CFLR EIR3≥0 5 (10) phase
default (0) or default (0)

Figure 3.2 Three class-of-service, MEF model (MEF 23 Table 2)

As describe in figure 3.2, the main KPIs used for Ethernet services are frame delay
(FD), frame delay variation (FDV) and frame loss ratio (FLR). Although MEF 23 is
being revisited to include values not currently defined, we can still use the table
as a reference tool for the different services. One attribute that is not currently
covered in the turn-up phase of the Ethernet services lifecycle is availability. As
it is a long-term variable (measured over months to a year’s period), we will not
address it in Ethernet services turn-up but rather in the Service-Monitoring chapter.

3– 5
 Carrier Ethernet Basics Educational Series 1 2 3 4 5 6

3.1.1 Business Services

Whether an Ethernet service provider or mobile backhaul service provider, all
operators face a number of similar challenges: They need to optimize the quality
of service (QoS) and reduce operational costs, while managing their network life
cycle effectively. They are required to deliver more and more complex solutions in a
reduced amount of time. Any service turn-up solution will need not only to validate
all their SLA parameters but also to take into account these challenges. The service
activation methodology ITU-T Y.1564 is the only one that addresses today’s realities.

When it comes to business services, there is a broad range of available KPIs to

choose from, depending on the application(s) being delivered and the geographic
range of the service. For example, a metro service will not have the same FD
constraints as a long-haul service.

Network Nature of QoS Classes

Performance Network
Parameter Performance Class Class Class Class Class Class 5
Objectives 0 1 2 3 4 Unspecified
IPTD Upper bound on 100 ms 400 ms 100 ms 400 ms 1s U
the mean IPTD
IPDV Upper bound 50 ms 50 ms U U U U
on the 1 x 10-3
quantile of
IPTD minus the
minimum IPTD
IPLR Upper bound on 1 x 10-3 1 x 10-3 1 x 10-3 1 x 10-3 1 x 10-3 1 x 10-3
the packet loss
probability
IPER Upper bound 1 x 10-4 U

Table 1 – Example of KPIs for IP services based on ITU-T Y.1541

Table 1 provides an upper limit for the different KPIs included in ITU-T Y.1541.
The IP packet transfer delay (IPTD), IP packet delay variation (IPDV), IP packet
loss ratio (IPLR) and IP packet error ratio (IPER) parameters can be leveraged to
provide guidance for the Ethernet service attributes that need to be validated.

From a best-practice perspective, the following KPI values are commonly

accepted for best effort (low priority) services: FD of 5 ms to 30 ms, FDV of 2 to
10 ms and FLR of 10-6.

3– 6
 Service Turn-Up

3.1.2 Mobile Backhaul Services

With its high bandwidth and low FD, FDV and FLR requirements, mobile backhaul
services have the most stringent SLA of all services. Figure 3.3 demonstrates the
evolution of mobile backhaul services requirements from an SLA and bandwidth
requirement perspective.

GSM WCDMA LTE

(assuming that the (assuming that the (assuming that the
primary service is primary services are primary services are
voice) voice and best-effort video (on-demand,
mobile broadband P2P), gaming, VoIP
connectivity) and best-effort mobile
broadband)
One-way delay Max: 40 ms Max: 30 ms Max: 20 ms
Target: 10 ms Target: 10 ms Target: 10 ms
Delay variation Max: 10 ms Max: 10 ms Max: 2 ms
Target: 5 ms Target: 2 ms Target: 1 ms
Packet loss rate Max: 10-3 Max: 10-3 Max: 10-3
Target: 10-4 Target: 10-6 Target: 10-6
Classes of service (Cos) 2 2 to 4 2 to 7
Availability 99.99 99.99 99.99
Typical backhaul per base 2:4:8 E1(2M) 6:20:50 Mbit/s 90:180:400+Mbit/s
station (Low:Med:High)

Figure 3.3 Typical SLA for mobile backhaul networks

Another interesting concept brought forward in figure 3.3 is the CoS evolution.
Through the evolution of technologies, the number of CoS evolved from two to a
maximum of seven. As Ethernet mobile backhaul services are mostly used for 3G
and 4G networks, we will concentrate on these technologies. When it comes to
Ethernet mobile backhaul services, the best guidance can be found in MEF 22
(Mobile Backhaul Implementation Agreement - Phase 1). Table 2 provides a view of
the service attributes for a four CoS service.

Service Class Name Bandwidth Profile CoS Performance Objectives

FD FDV FLR
Very High (H+) CIR>0 AFD AFDV AFLR
EIR=0
High (H) CIR>0 B FD B FDV B FLR
EIR=0
Medium (M) CIR>0 CFD CFDV CFLR
EIR≥0
Low (L) CIR≥0 DFD DFDV DFLR
EIR≥0*

Notes: A≤B≤C≤D and AFDV is as small as possible

(*) both CIR = 0 and EIR = 0 is not allowed as this results in no conformant Service Frames

Table 2 – Service class model for mobile backhauling (MEF 22 – Table 2)

3– 7
 Carrier Ethernet Basics Educational Series 1 2 3 4 5 6

Service Class Example of Generic Traffic Classes Mapping into CoS

Name
Four CoS Model Three CoS Model Two CoS Model
Very high (H*) Synchronization – –
High (H) Conversational, Conversational, and Conversational, and
Signaling and Control Synchronization, Synchronization,
Signaling and Control Signaling and Control
Medium (M) Streaming media Streaming media –
Low (L) Interactive and Interactive and Interactive and
Background Background Background

Table 3 – Examples of mobile backhaul traffic class mapping

into four, three and two CoS models

Table 3 maps different mobile applications to CoS categories, the most important
of which (in a four CoS model) is the very high service class that is used for
synchronization. Depending on the wireless technology in use, synchronization
ranges from very important to crucial in the delivery of quality services. As already
mentioned in previous chapters, there are two complementary technologies to
deliver Ethernet-based synchronization, PTP (IEEE 1588v2) and synchronous
Ethernet. As both have a high impact on network quality, they are covered more
thoroughly in the Service Turn-Up Test Methodologies section 3.3.

3.2 Test Architectures and Modes

Test architectures and modes are very important when it comes to Ethernet
services turn-up and troubleshooting. Each architecture and mode has economical
and technical advantages and limitations. Depending on the goals of the service
provider, a mix of test architectures and modes could be beneficial to deliver and
maintain quality services.

3.2.1 Test Architecture

There are two test architectures that can be leveraged to provide Ethernet service
turn-up:
• Distributed testing using portable test instruments connected to each test point
• Centralized test head placed strategically in the network

3.2.1.1 Distributed Test Architecture

The portable test instrument scenario is the classic test architecture. This scenario
is the most expensive test architecture as two portable instruments are deployed
and operated simultaneously. This translates into two simultaneous truck rolls
requiring coordination between both test ends. On the positive side, this test
scenario provides the best test performance as both ends use specialized test
equipment with complete and targeted test functionalities.

3– 8
 Service Turn-Up

3.2.1.2 Centralized Test Architecture

Centralized test scenarios implement active testing via test appliances that are located
at strategic locations throughout the network and then launching tests from these points
to portable devices located at other test points. The centralized test unit can be installed
in hard-to-reach places (such as central office cabinets and remote locations) and are
controlled remotely. This allows for test personnel and engineers to operate tests from
virtually any location. In some cases, however, test personnel must be sent to the end
points to complete testing. In such cases, portable equipment can be used by mobile
test personnel to execute either end-to-end or loopback tests. In such a scenario, testing
can occur at any point in the network, customer site or remote location.

Figure 3.4 provides a graphical example of a centralized test probe that can
connect to an end-device for testing purposes.

Figure 3.4 Centralized test architecture

3.2.1.3 Testing Using Network Interface Devices

A network interface device (NID) is a device that provides the demarcation between
the service provider and the customer. In the Carrier Ethernet world, this device
serves as the physical demarcation point providing the user-to-network interface
(UNI). NIDs also provide the traffi c-shaping, traffi c-policing and buffering functions
as part of the bandwidth profile defined by the MEF.

NIDs can also supply test functions such as loopback capabilities and support for
IEEE 802.1ag and ITU-T Y.1731 OAM. In active test scenarios, these devices are
configured and used as loopback devices. Testing can then occur from a centralized
test point to the NID loopback function or from a portable test device located at a
specifi c test point to the NID in loopback. Some network elements (such as Carrier
Ethernet switch routers) have a built-in NID function that allow the same OAM and
test capabilities as found in dedicated test NIDs. From a test perspective, there is
no difference in testing to a test NID or to a NID-enabled network element.

Ideally, NIDs are deployed at all handoff points and provide testing benefi ts. These
include reduced truck rolls as test loopback functions can be activated remotely.
Since the NID is always located at this point, there is no need to send test personnel
to the test site with a loopback device. Another benefit is simplified and accelerated
troubleshooting. A customer ticket can be assessed quickly by testing to this
loopback point to locate the problem spot (i.e., verify if the issue is found from the test
point to the NID location or between the NID location and the customer equipment).

3– 9
 Carrier Ethernet Basics Educational Series 1 2 3 4 5 6

3.2.1.4 Performance End-Point Unit

A performance end-point (PEP) unit is a cost-effective test demarcation device
that gives service providers remote visibility of their entire network. The PEP
unit acts as a test responder to any Ethernet test equipment and/or Ethernet
monitoring system. The PEP unit can be used throughout the network life-cycle:
turn-up, monitoring and troubleshooting.

As with a NID used during service turn-up, a PEP device loopbacks the test traffic
to a test instrument or probe, providing the test infrastructure required to perform
different tests without being in-line with traffic as a NID would.

3.2.2 Test Modes

3.2.2.1 Testing to a Loopback Function

The ITU-T Y.1564 Ethernet Service Activation Test Methodology can be executed
round-trip via the use of a loopback device (a PEP unit for instance). In this
case, the results reflect the effects of both test directions, from the test function
to the loopback point and back to the test set. In such a scenario, the loopback
functionality can be performed by another test instrument in Loopback mode or by
a PEP device in Loopback mode.

3.2.2.2 Testing a Dual Test-Set Scenario

The ITU-T Y.1564 Ethernet Service Activation Test Methodology can also be run
in Dual Test-Set mode, as shown in Chapter 2. In this scenario, two test sets,
one designated as local and the other as remote, are used to communicate and
independently run tests per direction; this provides supplementary test flexibility.

Results from both directions are sent and displayed on the local unit. This ensures
that the entire test routine can be completed by a single person in control of both
test instruments from a single unit, providing reduced test time and manpower. This
flexibility also ensures that different units can be set as the remote unit. The most
interesting scenario is a test unit at a centralized point that is always configured
as a remote unit, configured with fixed addresses. The carrier can simply dispatch
a single test person to a test site to quickly discover and execute service turn-up
and burn-in efficiently without requiring an extra worker in the central office.

The dual test-set approach also provides the capability to segment the network
and quickly pinpoint in which direction the issues occur. This is especially
important in cases where bandwidth is different between the upstream and
downstream direction. In such cases, using a loopback tool will always yield the
same results since the measurement will be affected by the lowest throughput and
the test results will not show that one direction has higher performances than the
other. With the dual test-set approach, both directions are independently analyzed
at the same time and pass/fail results are provided per direction.

In Figure 3.5, the bandwidth is 30 Mbit/s in one direction and 70 Mbit/s in the
other direction. Measuring the bandwidth in one direction will not be sufficient;
therefore a bidirectional test is required.

3– 10
 Service Turn-Up

Executing the test in one direction at a time is a good troubleshooting method;

however, network elements behave differently when unidirectional test traffic and
bidirectional traffi c is used. In unidirectional traffi c generation, the CPU of the
network element only processes traffic in one direction, therefore using its full
switching capabilities to this one direction. In Bidirectional Traffi c mode, the CPU
is exercised with test traffi c coming from both directions, refl ecting the real-world
environment. The bidirectional test methodology ensures that the circuit is fully
stressed in both directions by ensuring that they are always tested at the same
time. This is mandatory when assessing the performance of services during the
turn-up phase.

Figure 3.5 Bidirectional Test Example

3– 11
 Carrier Ethernet Basics Educational Series 1 2 3 4 5 6

3.3 Service Turn-Up Test Methodologies

There are currently two standardized test methodologies used for service turn-up:
RFC 2544 and ITU-T Y.1564.

As previously mentioned in section 2.1 of Chapter 2, RFC 2544 is the traditional

methodology when it comes to service turn-up. Unfortunately, this methodology
was created to assess the performance of network elements in a lab environment
and not turn-up services in the field. As defined in the test methodology, RFC
2544 has drawbacks since it only validates part of the service attributes; it is
very long to complete (the latency test duration is 4.66 hours on its own), and the
test coverage of the methodology is very limited. Due to the fact that we find that
this methodology is not well-suited to service turn-up, we will concentrate on our
recommended standardized test methodology: ITU-T Y.1564.

3.3.1 ITU-T Y.1564 Ethernet Service Activation Test Methodology

Whether an Ethernet service provider or mobile backhaul service provider, all
operators are faced with a number of challenges. They need to optimize QoS and
reduce operational costs while managing their network life cycle effectively. They
are challenged to deliver more and more complex solutions in a reduced amount
of time. Any service turn-up solution will need not only to validate all their SLA
parameters but to also take into account those challenges. The service activation
methodology ITU-T Y.1564 is the only one that addresses today’s realities. As
previously mentioned in Chapter 2, there are two tests that make up ITU-T Y.1564:

• The service configuration test is a per-service test that measures and verifies
bandwidth and performance requirements of a specific service as defined by
the user. The process follows three key phases and monitors all performance
indicators during these phases, ensuring that they are all met at the same time.

• The service performance test provides a snapshot of the performance of all

delivered services during their normal state of operation. The next section will
provide more detailed information on each test.

3.3.1.1 ITU-T Y.1564 Service Configuration Test

There are three phases of testing to perform per service, meaning that if multiple
services exist on the network, each service should be tested one at a time.
This ensures that there is no interference from other streams and that the
bandwidth and performance of a specific service is being measured.

3– 12
 Service Turn-Up

Phase 1: From Minimum to CIR

In this phase, bandwidth for a specific service is ramped up from a minimum data
rate to the committed information rate (CIR). This phase ensures that the network
is able to support this specific service at different data rates while maintaining
performance levels. It also provides a safe and effective way to ramp up utilization
without overloading a network in case the service is incorrectly configured.

The suggested ramp-up is by increments of 25%, starting at 25% of the CIR.

The final step is testing at the CIR rate. This methodology ensures a quick
assessment of the behavior of the network as the service is ramping up. For finer
granularity, the ramp-up can be adjusted to smaller values. If any performance
parameter or frame loss occurs, the test shall be declared as failed since the
service requirements are not met.

Expected results:
CIR
• RX throughput = TX throughput
√ • KPIs < Fail threshold

• RX throughput = TX throughput
• KPIs > Fail threshold

Figure 3.6 Minimum to CIR bandwidth ramp-up

Phase 2: Testing at CIR to CIR + EIR

In this phase, the service is ramped-up from the CIR to the excess information rate
(EIR). This step ensures that the service’s EIR is correctly configured and that the
EIR rate can be attained. However, as by accepted principles, performance is not
guaranteed in the EIR rates, therefore no performance assessment is performed
at this stage. The focus of the test is essentially to ensure that the service can
support EIR without any frame loss.

Expected results:
CIR + EIR
CIR
√ • RX throughput = TX throughput
• KPIs not monitored

• RX throughput < CIR

Figure 3.7 CIR to EIR bandwidth ramp-up

3– 13
 Carrier Ethernet Basics Educational Series 1 2 3 4 5 6

Phase 3: Overshoot Testing

One of the attributes of packet transport is the capability to handle bursty traffi c.
In conditions of burst, overshoot environments that exceed the EIR can occur,
usually leading to discarded traffic.

In this step, traffic is sent above the EIR and the receive rate is monitored.
The expected throughput is essentially the EIR as any traffi c over the EIR should be
discarded as red traffic. If more traffic than the EIR is received, this would indicate
that a device is not properly configured and thus a fail condition shall be declared.

Discard Expected results:

CIR + EIR
CIR
√ • RX throughput = EIR + CIR
• KPIs not monitored,

• RX throughput > EIR + CIR or CIR

Figure 3.8 Overshoot testing

3.3.1.2 ITU-T Y.1564 Service Performance Test

While the service configuration test focused on the proper configuration of each
service in a network element, the service performance test focuses on testing the
actual service and the enforcement of the QoS parameters under CIR conditions.

In this test, all configured services are generated at the same time at CIR for a
soaking period that can range from a few minutes to days. During this soaking
period, the performance of each service is individually monitored, and if any service
fails to meet its performance parameters, a fail condition is declared.

CIR Service 3 Service test pass/fail criteria:

Service 3
CIR Service 2
√ • KPIs within SLA per service
Service 2

CIR Service 1 • Any KPI fails

Service 1

Figure 3.9 ITU-T Y.154 service performance sample test results

The combination of the service configuration and performance tests provides critical
results in a simple and complete test methodology. It quickly identifies configuration
faults via the network configuration tools by focusing on each service and how they
are handled by the network elements along the paths. This test suite then focuses
on the network capacity to handle and guarantee all the services simultaneously.
Once both phases are passed, the circuit is then ready to be activated and be put
in service.

3– 14
 Service Turn-Up

3.4 Birth Certificate

When the service turn-up and burn-in is complete, reports must be created in
order to provide traceability and reference before the circuit is delivered to the
customer or placed in service.

These reports may include the following:

• P
hysical test report: This collection of reports includes physical testing
results (such as OTDR traces and layer 1 BER tests) to prove that the physical
specification of the new circuit is met.

• S
ervice turn-up report: This report proves that service handling has been
correctly configured on the forwarding devices and that the performance meets
the service activation criteria.

• Burn-in report: This report (based on the ITU-T Y.1564 methodology) provides
performance details for services tested for a medium period (from 24 to 72 hours).
The report provides a description of the services and the average and maximum
values of the KPI measured.

The collection of these test reports is now the birth certificate of the circuit.

BIRTH CERTIFICATE

TURN-UP RESULTS BURN-IN RESULTS

Physical report: Burn-in results: Birth certificate:

• Link quality • Services testing • Complete performance
• Physical testing • End-to-end quality assessment of the circuit

Service turn-up report:

• Per-service performance

Figure 3.10 Birth certificate components

3– 15
 Carrier Ethernet Basics Educational Series 1 2 3 4 5 6

3.5 Sample Applications

The ITU-T Y.1564 service activation methodology is recommended for business
and mobile backhaul services turn up. The KPIs measured are the same (i.e.,
bandwidth, frame loss ratio, frame transfer delay and inter-frame delay variation),
however, the SLAs could vary. The following sections provide sample SLA
configurations and turn-up testing scenarios.

3.5.1 Business Ethernet Services

The figure below shows an example of an SLA for three services: data, voice
and video. With ITU-T Y.1564, the administrator can configure three classes of
service: data, voice and video. Each service has its own VLAN as well. All the SLA
parameters need to be validated during the service turn-up phase.

Performance Attribute Data Voice Video

CIR (Mbit/s) (green traffic) 50 0.12 3.97
EIR (Mbit/s) (yellow traffic) 0 5 5
Frame delay (ms) <6 <15 <15

Frame delay variation (ms) <1 <2 <2

Frame loss (%) <0.001 <0.1 <0.1

VLAN 100 200 300

Figure 3.11 Sample business Ethernet SLA configuration

3.5.1.1 Service Configuration Test

In addition to defining the SLA requirements, the administrator could also choose
the ramp-up steps. As suggested earlier, the steps can be set to 25% of the
committed information rate (CIR). The KPIs will be measured for each step and
each service. The figure below shows the service configuration results of the
example above.

Step CIR (%) Frame Max Jitter Max Latency Verdict Average Throughput
Loss (%) (ms) (ms) (Mbit/s)
1 50.0 0.0 0.100 5.051 √ 1.988
2 75.0 0.0 0.098 5.051 √ 2.981
3 90.0 0.0 0.098 5.051 √ 3.577
CIR 100.0 0.0 0.098 5.051 √ 3.974
Overshoot 0.0 0.100 5.051 √ 4.002

Figure 3.12 Sample business Ethernet service configuration results

All the SLA parameters are met in this case; therefore, the network is configured
properly and can allow traffic from all three services simultaneously.

3– 16
 Service Turn-Up

3.5.1.2 Service Performance test

Once the service configuration tests are completed successfully, the next step is
to run a service performance test for all three services. In this phase, the SLA
parameters will be measured for all services simultaneously. The administrator can
choose to run a test for a short or long period (24 hours or even a few days) for a
burn-in test. Below are the service performance results of the example above.

Service Average Frame Max Jitter Max Latency Verdict

No. Throughput Loss (%) (ms) (ms)
(Mbit/s)
1 50 0.0 0.262 5.179 √
2 0.125 0.0 0.296 5.175
3 3.972 0.0 0.259 5.051 √

Figure 3.13 Sample business Ethernet service performance results

The results obtained from the service configuration and service performance tests
can be used to issue a birth certificate.

3.5.2 Mobile Backhaul Services

During the service turn-up phase of mobile backhaul services, different SLA
parameters are validated depending on the type of wireless network technology
used. The SLA below is one that can be used for an LTE network service turn-up.
At least seven services need to be tested in this case. The administrator needs to
set-up seven classes of service. Just like in the previous example, the administrator
can use the ITU-T Y.1564 service configuration and service performance tests to
validate the SLA parameters of all seven services.

LTE Traffic Transport Service Class PCP DSCP LTE Interface

Synchronization Synchronization 7 111xxx Sync
Bearer OAM Bearer OAM 4 100xxx OAM
1/2 Voice/line video 6 110xxx S1. X2
3 Voice on demand 3 011xxx S1. X2
QC | Level 4 Real-time gaming 5 101xxx S1. X2
5 Control/management 7 111xxx S1. X2
6/7/8/9 Others 0,1,2 000xxx-010xxx S1. X2

Figure 3.14 Sample mobile Backhaul service SLA configuration

3– 17
 Carrier Ethernet Basics Educational Series 1 2 3 4 5 6

One-Way Latency

One important KPI that is measured for mobile backhaul services is frame delay
(latency). In most cases, the round-trip latency (i.e., the time required for traffic to
go across a network and back to the original point) is measured during turn-up.
In Ethernet services the latency between two points is usually the same in both
directions, therefore it is half of the round-trip delay.

When determining the time, PTP IEEE 1588v2 assumes a symmetrical link
between the master and slave clocks. It is therefore important to measure the
latency in each direction in order to make sure they are both the same. The one-
way latency, which is the duration it takes traffic from the master clock to the slave
clock, needs to be measured in this scenario.

3.5.3 Synchronization
The synchronization service turn-up and burn-in phase allows network engineers
to qualify the ability of the network to properly service the synchronization traffic
according to its configured priority, and to verify the performance of the network
synchronization flow under simulated or real-life loading conditions. As a service,
typical testing should focus on the key performance indicators of frame delay
variation, frame delay and frame loss and the influence of other streams on the
synchronization stream during congestion or high network utilization conditions.

The burn-in phase is an essential testing phase where the flow is soaked for a
longer test period to assess its stability under various load conditions. This phase
provides an assessment of the stability of the network synchronization flow over a
longer test period and provides a good indication of the capability of the network
to efficiently transport multiple services while maintaining the performance of the
synchronization flow.
IEEE 1588 and
SyncWatch-110 Frequency

IEEE
SSU Grand 1588v2
Master (GM) IEEE
1588v2
1

GigE
0
G
ig
E
C
S

o
O
N

re
E
T/
S
D
H

T1/E1

TDM
Frequency
G
ig
E
M
et
ro

T1
SyncWatch-110

Data Center SyncE

TDM

SyncWatch-110
TDM Frequency

Figure 3.15 Sample Ethernet synchronization network

3– 18