Ethernet vs-mpls-tp-in-the-access-presentation

Ethernet vs. MPLS-TP in the Access Slide 1

Ethernet vs. MPLS-TPin Access Networks

Yaakov (J) Stein

CTO

RAD Data Communications


Agenda

Is MPLS-TP ready to replace Ethernet as the packet technology that dominates access networks?

• Brief review of access networks

• Characteristics of Ethernet and MPLS-TP

• Technical comparison: Ethernet vs. MPLS-TP


Access Networks


Core:MPLS or IP

interface(and theoretically PBB)

Access Network Considerations

Access Network:Q-in-Q Ethernet?

MPLS-TP ?

Residential Customers

(IP)

Business Customers(IP or Ethernet)

Cell Sites(IP and/or Ethernet

and/or TDMand Timing)

Other customer

sites

Other customer

sites

InternetData

Centers


CoreNetwork:

MPLS

Customer Network: Ethernet

Why Ethernet and MPLS-TP ?

• Ethernet started in customer networks (LAN) and over the years has moved into the access network (MEF)

• MPLS started in the core network and is now trying to conquer the access network

Access Network

First Mile

Last Mile


Access Network Segmentation

A recent trend is to segment the access network into:• First/Last Mile

– Provides connectivity from customer site to first access node

– Leverages physical layer technologies such as DSL, active/passive fiber, microwave, HSDPA+, LTE, …

• Middle Mile– Collects and aggregates traffic from multiple access nodes

– Provides backhaul towards core

First/Last Mile Middle Mile

+Access Node

NTU/CLE

AggregationBackhaul

Access Network


Access / Core Differences (1)

Differences between core and access networks may translate to protocol requirements differences:

Core Access Impact

No. of NetworkElements

Few – routers, LSRs, switches

Many – CPEs, NTUs, DSLAMs, aggregators

• Strong pressure on access NE price levels

• Access needs to be as “touchless” as possible

Data Rates Higher Lower • Core may guarantee QoS by resource over-provisioning

• Access needs QoS mechanisms


Access / Core Differences (2)

Core Access Impact

Topology Richly connected Simple – typically trees or rings

• Fault in access network affects fewer people, but fewer bypass options

• Core can get away with fast rerouting

• Access network requires OAM and planned APS

Security “Walled garden”: • Strong security

to and from the outside world

• Loose security on the inside

Easily accessible • Customer networks alsoconsidered walled gardens

• Impractical to protect the entire access network


Ethernet and MPLS-TP Overview


Ethernet / MPLS-TP Differences (1)

While both Ethernet and MPLS are commonly used to carry IP,there are some fundamental protocol differences:

Ethernet MPLS-TP

OSI Layer L0-L2 (but may run over MPLS)

Requires a server layer to transport it (which may be Ethernet)

Packet Identification

Frames are inherently self-describing

No PID

Scope Destination address: Global, not aggregated

Only locally-meaningful labels

Source Identifier

Unique source address No source identifier

Clients IP and other IP and other

Transport Over SDH/SONET, OTN Over SDH/SONET, OTN


Ethernet / MPLS-TP Differences (2)

Ethernet MPLS-TP

OAM and Protection

•Fault Management•Performance Monitoring•APS

•Fault Management•Performance Monitoring•APS

IP Protocols • No routing protocol defined

• A number of L2CPs

Leverages the entire IP suite of protocols

Loop Tolerance

No Can tolerate transient loops (has TTL field)

PriorityMarking

•3-bit (e.g., DiffServ)• “Drop Eligibility”

3-bit (DiffServ)

Additional Dedicated Tools

•Bandwidth Profiles•Timing over Packet•Security (MACSec)

None have been defined

Developed By • IEEE•Multiple competing SDOs

• IETF•Multiple competing SDOs


Ethernet and MPLS-TP: Face-Off


Comparison Criteria

1. Fault Management Functionality

2. Performance Management Functionality

3. Automatic Protection Switching Mechanisms

4. Quality of Service Mechanisms

5. Traffic – Handling Diverse Client Types

6. Timing – High Accuracy Time and Frequency Distribution

7. Integration with Surrounding Networks

8. CapEx

9. OpEx

10. Security

Each will be scored for:Suitability: 2 pointsCoverage: 4 pointsMaturity: 4 points


Fault Management Functionality:The Arguments

The Need: Access networks require strong FM capabilities to minimize down-time

Ethernet• Two OAM mechanisms (Y.1731/CFM and EFM)• Unique source address, particularly amenable to trace-back functionality• Q-in-Q is not true client-server, but this is covered up by MEL• Y.1731 is full-featured – comprehensive set of FM TLVs • EFM is more limited, but adds dying gasp critical for CPEs• Interop issues of both OAMs have finally been resolved; remaining details

are resolved via implementation agreements (e.g., MEF-30)

MPLS-TP• Had basic heartbeats (BFD) and diagnostics (LSP-ping)• The IETF designed MPLS-TP FM based on the Generic Access Channel and:

• BFD for CC• LSP-ping for on-demand diagnostics• New frame formats to fulfill specific requirements


Fault Management Functionality:The Verdict

Ethernet MPLS-TP

SuitabilityHighly suited (SA)

No true address, requires extra work

2 Points 1 Point

Coverage

Y.1731 is full featured, EFM fulfills its requirements

MPLS-TP FM similar to CFMbut missing dying gasp

4 Points 3 Points

Maturity

Y.1731 and EFM are interoperable and widely

deployed

Some MPLS-TP features are seeing initial trials

4 Points 1 Point

Total 10 Points 5 Points


Performance Management Functionality:The Arguments

The Need: Useful tool for maintenance and diagnostics of the access network

Ethernet

• The ITU Y.1731 supports PM (loss, delay, PDV, …) using a request-response model; IEEE 802.1ag does not

• Y.1731 is used as the basis for commissioning procedures (Y.1564)

• Widespread vendor interoperability has been demonstrated

MPLS-TP• RFCs 6374, 6375 define a set of PM functions based on the GA Channel

• These functions were designed to be HW friendly, yet flexible- Support byte or packet counters- 1588 or NTP-style timestamps- Traffic-counters or synthetic loss

• Implementations have yet to be announced


Performance Management Functionality:The Verdict

Ethernet MPLS-TP

SuitabilityNeither protocol has an inherent advantage or disadvantage

2 Points 2 Points

CoverageSupports all features

Supports all features (may be more flexible)

4 Points 4 Points

Maturity Y.1731 is finally interoperable

MPLS PM is not (widely) implemented

4 Points 0 Points



Automatic Protection Switching:The Arguments

The Need: APS is a complex subject, requiring careful protocol work and proper configuration. Solutions required for both linear and ring protection

Ethernet

• Ethernet has a particular problem with rings• There are many open loop ring protection (e.g., G.8032) but these are not

compatible with QoS mechanisms

MPLS-TP

• MPLS in the core exploits Fast ReRoute (RFC 4090) instead of APS• But FRR requires rich interconnection and so is usually not applicable

to access networks

• The IETF has standardized RFC 6378 for MPLS-TP linear protection• There are also proposals for ring protection


Automatic Protection Switching:The Verdict

Ethernet MPLS-TP

SuitabilityNot suitable for ring protection

No particular strengths or weaknesses

0 Points 2 Points

Coverage

G.8031/G.8032 fulfill current requirements

RFC 6378 (linear protection); no ring protection RFC yet

3 Points 2 Points

Maturity

G.8031/G.8032 have been extensively debugged and

updated

MPLS-TP only partially finalized and not yet

deployed

4 Points 1 Point



Quality of Service:The Arguments

Two types of QoS need to be considered to manipulate traffic:1. Hard QoS (engineering): Connection Admission Control, Resource Reservation2. Soft QoS (conditioning): Priority marking, discard eligibility, queuing, bucketing

Ethernet

• PBB-TE (PBT) defines hard QoS, but is not widely implemented• P-bits for prioritization marking; discard eligibility marking in S-VLANs• MEF’s BW profile defines a bucketing algorithm• Ethernet headers are self-describing – support Traffic Awareness

MPLS-TP

• MPLS-TE supports resource reservation but traffic engineering may not be relevant for access networks

• Traffic Class (and L-LSPs) support DiffServ prioritization application awareness – MPLS packets are not self-describing

• DPI is required for Traffic Awareness


Quality of Service:The Verdict

Ethernet MPLS-TP

SuitabilitySupports all QoS types

Does not define for (bucket-based) traffic conditioning

2 Points 1 Point

Coverage

MEF standards have been proven

Without bucketing,MPLS is at a disadvantage

4 Points 3 Points

Maturity

BW profiles are standardized;certification programs

MPLS-TP – nothing special

4 Points 0 Points



Traffic types:The Arguments

The Need: No transport protocol is useful if it can’t transport the required client traffic

Ethernet

• Differentiates traffic via Ethertype marking or LLC• Can directly carry IPv4, IPv6, MPLS, Ethernet, fiber channel, and low-

rate TDM (MEF-8)

• Does not directly carry other legacy traffic types (e.g., ATM, frame relay)• Can be carried indirectly via PHP’ed MPLS PWs

MPLS-TP

• Can carry IPv4, IPv6, MPLS, and PWs (and through which Ethernet, Fiber Channel and all legacy types)

• Defining a new PW type requires IETF consensus but the new packet-PWprovides more freedom

Neither is universal but existing mechanisms can be extended to cover new cases


Traffic types:The Verdict

Ethernet MPLS-TP

Suitability

Supports arbitrary clients via Ethertypes

Supports arbitrary clients via PWs

2 Points 2 Points

Coverage

Does not support all legacy traffic types (ATM, FR)

Supports most traffic types via PWs

2 Points 3 Points

Maturity

Ethertypes have been widely deployed

PWs have been widely deployed

4 Points 4 Points



Timing:The Arguments

The Need: Distribution of highly accurate timing (frequency and Time of Day)is crucial for some access network applications, notably cellular backhaul

Ethernet

Two protocols have become standard for this purpose:1. Synchronous Ethernet (SyncE) is Ethernet-specific2. IEEE 1588-2008 (defined for Ethernet and UDP/IP) for Timing over

Packet; on-path support elements (Boundary Clocks or Transparent Clocks) have only been defined for Ethernet

MPLS-TP

• MPLS does not define a physical layer

• The IETF TICTOC WG is presently working on 1588oMPLS


Timing:The Verdict

Ethernet MPLS-TP

Suitability

Supports ToP and defines a physical layer to support SyncE

May be able to support 1588 but there can be no

SyncMPLS

2 Points 1 Point

Coverage

Meets all requirements with SyncE, 1588, BC, TC

1588oMPLS to support ToP may be coming

4 Points 1 Point

Maturity

ITU-T has defined profile(s) for 1588 use

MPLS presently has no timing support

4 Points 0 Points



Integration:The Arguments

The access network needs to integrate with the core and customer networks. Cost and complexity will be minimized by a smooth hand-off, i.e., access protocol compatibility with other network protocols• Customer networks may have Ethernet or TDM interfaces (IP over Ethernet,

Ethernet over TDM, Ethernet over SDH)• Core networks are usually MPLS (IP over MPLS, MPLS over Ethernet, MPLS

over SDH)

Ethernet

• Ethernet in the access is a perfect match for customer networks

• Can not seamlessly interface with MPLS core

MPLS-TP• A reasonable match for customer network protocols since they can be

tunneled over MPLS• Reuses existing MPLS standards thus maximizing compatibility


Integration:The Verdict

Ethernet MPLS-TP

Suitability

Perfect match for customer network, but not for core

Best match for core network, but not for

customer

1 Point 1 Point

Coverage

Ethernet Q-in-Q and MAC-in-MAC perfect customer hand-

off

Does not require GW for forwarding to core, but

control protocols may not interconnect

3 Points 2 Points

Maturity

Ethernet Q-in-Q presently widely deployed

Seamless MPLS still in its infancy

4 Points 1 Point



CapEx:The Arguments

The Need: Access network providers need to keep their costs down; due to the large number of Network Elements, access networks are CapEx-sensitive

Ethernet

• Ethernet switching fabrics are inherently non-scalable (long global addresses can’t be aggregated)

• Due to popularity, Ethernet switches are inexpensive (high volumes, large R&D investment in cost reduction)

• However, carrier-grade Ethernet switches need extra functionality• Ethernet supports CapEx-saving architectures (e.g., EPON)

MPLS-TP

• LSRs are complex and expensive – reducing the price of NEs (MPLS switchinstead of MPLS router) was the unstated motivation for MPLS-TP

• Pure MPLS NEs have simple forwarding engines and thus should be less expensive than Ethernet switches, but still require Ethernet or SDH or OTN interfaces


CapEx:The Verdict

Ethernet MPLS-TP

Suitability

Inexpensive, but can not scale forever

Allows for significant cost reduction vs. full LSR

1 Point 2 Points

Coverage

R&D and volumes have driven down Ethernet CapEx

MPLS-TP-specific devices can be low cost

4 Points 4 Points

Maturity

MEF certification programs for carrier-grade Ethernet switches

Many trials are using LSRs; chip sets are starting to

come out to address

4 Points 2 Points



OpEx:The Arguments

• OpEx considerations that are taken into account:- Direct operations cost - Staffing- Minimizing “unchargeable” overhead

• Reduction of direct operations costs for networks with large number of NEs :- Equipment must work reliably and be interoperate- Minimum touch (auto-discovery, zero-touch configuration., etc.)- Use of FM, Control Plane or Management Plane protocols

• Maintaining competent staff requires:- Availability- Training- Employee retention

• Overhead minimization applies to: - Per packet overhead - OAM, CP/MP packets


OpEx:The Arguments (Cont’)

Ethernet• Basic Ethernet is zero-touch by design but carrier-grade may add many

configuration parameters• A large number of useful L2CPs (STP, ELMI, GVRP) but no universal CP

protocol• In addition to equipment certification, MEF has initiated certification for

carrier Ethernet engineers• Main Ethernet overhead is large, but tags add only a small delta

MPLS-TP

• Basic MPLS relies on IP routing protocols but TP is designed to be able to function w/o CP

• GMPLS CP has been defined as an option• Can operate without IP forwarding (eliminating IP logistics); CP and MP

can be carried in GACh (although not yet developed)• Specific vendors have expert certifications but none specific to MPLS-TP• Same look and feel as other transport networks to minimize retraining• May leverage extensions to existing OSS


OpEx:The Verdict

Ethernet MPLS-TP

Suitability

Metro Ethernets have been shown to be low OpEx

Designed to be inexpensively maintainable

2 Points 2 Points

Coverage

Inelegant CP, available staff, medium overhead

Learned from previous efforts

4 Points 4 Points

Maturity

Extensive experience and certification programs

Extensive operational experience only partially

applicable

4 Points 2 Points



Security:The Arguments

The Need: Security is perhaps the most important telecomm issue today

• OAM, APS, QoS mechanisms are powerless to cope with Denial of Service attacks

• Access network NEs are frequently physically unprotected, so:

1. Ports must be protected2. Packets must be authenticated and integrity checked 3. Confidentiality mechanisms may be needed4. MPs and CPs must be hard-state


Security:The Arguments (Cont’)

Ethernet

• Ethernet packets carry unique authenticatable source addresses• MACsec and its 802.1X extensions define mechanisms that can be used to

protect carrier networks (although hop-by-hop security model may not always be ideal)

MPLS-TP

• MPLS was designed for core networks (walled gardens) with the assumption that there are no inside attacks

• Forwarding plane attacks based on lack of authentication/integrity• Control plane attacks based on soft state of protocols


Security:The Verdict

Ethernet MPLS-TP

Suitability

Has an authenticatable unique SA

Has no source identifier and uses soft-state CPs

2 Points 0 Points

Coverage

MACsec and 802.1X, but may need more

Little positive support (but it does support attacks …)

3 Points 1 Point

Maturity

MACsec is starting to appear in standard chipsets

MPLS community is not addressing the TP security

problem

2 Points 0 Points



Summary: Final Score

Caveats:

• Deployments have particular (non)requirements, but all 10 considerations were given equal weight

• Some coverage and all maturity scores will change over time

Suitability Coverage Maturity Total

Ethernet 16/20 35/40 38/40 89

MPLS-TP 14/20 27/40 11/40 52

Note: MPLS-TP lost

• 29 points due to lack of maturity

• 9 points due to lack of security


For information about RAD’s Ethernet Access solutions, visit www.ethernetaccess.com

www.rad.com

Technology

Ethernet vs-mpls-tp-in-the-access-presentation