Ethernet Services using BGP MPLS Based Ethernet … · 03-12-2011 · Ethernet Services using BGP MPLS Based Ethernet VPNs (EVPN) Issue: 2 Issue Date: TBD 2017 1 . Ethernet Services

TECHNICAL REPORT

© The Broadband Forum. All rights reserved.

TR-350

Ethernet Services using BGP MPLS Based Ethernet VPNs (EVPN)

Issue: 2

Issue Date: TBD 2017

1

Ethernet Services Using BGP MPLS based EVPNs TR-350 Issue 2

TBD 2017 © The Broadband Forum. All rights reserved 2 of 65

Notice 2 3 The Broadband Forum is a non-profit corporation organized to create guidelines for broadband 4

network system development and deployment. This Broadband Forum Technical Report has been 5

approved by members of the Forum. This Broadband Forum Technical Report is not binding on 6

the Broadband Forum, any of its members, or any developer or service provider. This Broadband 7

Forum Technical Report is subject to change, but only with approval of members of the Forum. 8

This Technical Report is copyrighted by the Broadband Forum, and all rights are reserved. 9

Portions of this Technical Report may be copyrighted by Broadband Forum members. 10

11

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, 12

AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY 13

DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE 14

IMPLEMENTER'S OWN RISK, AND NEITHER the Forum, NOR ANY OF ITS MEMBERS OR 15

SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER 16

OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY 17

OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION. 18

19

Broadband Forum Technical Reports may be copied, downloaded, stored on a server or otherwise 20

re-distributed in their entirety only, and may not be modified without the advance written 21

permission of the Broadband Forum. 22

23

The text of this notice must be included in all copies of this Broadband Forum Technical Report 24

25



26

Issue Number Approval

Date

Publication Date Issue Editor Changes

1 9 Nov. 2015 11 Nov. 2015 Rao Cherukuri,

Juniper

Sriganesh Kini,

Ericsson

Original

bbf2016.691.00 TBD TBD Rao Cherukuri, BBF

Distinguished Fellow

Steven Blake,

Ericsson

Added Sec.

13 EPL and

EVPL



Steven Blake,

Ericsson

Correct [51]

URL, R-81;

fix editorial

nits.



Steven Blake,

Ericsson

Same as .01

with all

changes

accepted. WT-350 ELine Modifications from bbf2016.691.02-Cherukuri-DF-bbf2016.691.doc

TBD TBD Rao Cherukuri, BBF


Steven Blake,

Ericsson

Same as .02

with changes

for

Bandwidth

Policy and

updated

figures for

Eline. WT-350 ELine final Modifications from bbf2016.691.02-Cherukuri-DF-bbf2016.691.docx



Same as

above with

changes for

ETree.

WT-350 ELine

final

Modifications

from

bbf2016.691.02

-Cherukuri-DF-

bbf2016.691.do

cx



Proposed SB

Candidate

WT-

350i2ELineETr



SB Text

https://wiki.broadband-forum.org/download/attachments/20743573/WT-350%20ELine%20Modifications%20from%20bbf2016.691.02-Cherukuri-DF-bbf2016.691.doc?api=v2






https://wiki.broadband-forum.org/download/attachments/20743573/WT-350%20ELine%20final%20Modifications%20from%20bbf2016.691.02-Cherukuri-DF-bbf2016.691.docx?api=v2


















ee.SBCandidate

-Sinicrope-

RnTWAD

28

29

30

31

Comments or questions about this Broadband Forum Technical Report should be directed to 32

[email protected]. 33

34

35

Editor Rao Cherukuri BBF Distinguished Fellow

Steven Blake Ericsson

Routing and Transport

WA Director

David Sinicrope

Ericsson

mailto:[email protected]



TABLE OF CONTENTS 36

EXECUTIVE SUMMARY ........................................................................................................... 10 37

1 PURPOSE AND SCOPE ....................................................................................................... 11 38

PURPOSE .............................................................................................................................. 11 39

SCOPE .................................................................................................................................. 11 40

2 REFERENCES AND TERMINOLOGY ............................................................................. 13 41

CONVENTIONS ..................................................................................................................... 13 42

REFERENCES ........................................................................................................................ 13 43

DEFINITIONS ........................................................................................................................ 16 44

ABBREVIATIONS .................................................................................................................. 17 45

3 TECHNICAL REPORT IMPACT ...................................................................................... 19 46

ENERGY EFFICIENCY ............................................................................................................ 19 47

IPV6 ..................................................................................................................................... 19 48

SECURITY ............................................................................................................................. 19 49

PRIVACY .............................................................................................................................. 19 50

4 CARRIER ETHERNET SERVICES ................................................................................... 20 51

CARRIER ETHERNET REQUIREMENTS ................................................................................... 20 52

5 LAYER 2 ETHERNET VPNS IN MPLS NETWORKS .................................................... 21 53

6 REFERENCE ARCHITECTURE ....................................................................................... 22 54

GENERAL REFERENCE ARCHITECTURE ................................................................................ 22 55

MPLS FOR CARRIER ETHERNET IN BROADBAND ACCESS & AGGREGATION ....................... 23 56

6.2.1 Multi-Service Broadband Access & Aggregation .................................................... 23 57

6.2.2 TR-178 Architectures ............................................................................................... 23 58

7 SIGNALING AND ROUTING ............................................................................................. 24 59

LSP SIGNALING ................................................................................................................... 24 60

7.1.1 Multi-area LSP Signaling ........................................................................................ 24 61

ROUTING .............................................................................................................................. 26 62

8 OAM ........................................................................................................................................ 27 63

ETHERNET OAM.................................................................................................................. 27 64

8.1.1 Link OAM ................................................................................................................. 27 65

8.1.2 ITU-T G.8013/Y.1731 .............................................................................................. 28 66

MEF SERVICE OAM ............................................................................................................ 28 67

MPLS OAM ........................................................................................................................ 29 68

8.3.1 LSP OAM ................................................................................................................. 29 69

8.3.2 Convergence ............................................................................................................ 30 70

9 QOS ......................................................................................................................................... 32 71

TUNNEL COS MAPPING AND MARKING ................................................................................. 32 72

10 PSN RESILIENCY ........................................................................................................ 33 73



FAILURE DETECTION ............................................................................................................ 33 74

LSP RECOVERY .................................................................................................................... 33 75

CONTROL PLANE RESILIENCY ............................................................................................... 34 76

11 BGP MPLS-BASED ETHERNET VPN ...................................................................... 35 77

REFERENCE ARCHITECTURE AND OVERVIEW ...................................................................... 35 78

EVPN SERVICE INTERFACES ............................................................................................... 36 79

11.2.1 VLAN-Based Service Interfaces ............................................................................... 36 80

11.2.2 VLAN Bundle Service Interfaces .............................................................................. 36 81

11.2.3 VLAN-Aware Bundle Service Interfaces .................................................................. 37 82

DATA PLANE ........................................................................................................................ 37 83

11.3.1 Underlying PSN transport ....................................................................................... 37 84

11.3.2 VPN encapsulation................................................................................................... 37 85

11.3.3 VID Translation ....................................................................................................... 37 86

11.3.4 Frame Ordering ....................................................................................................... 37 87

CONTROL PLANE.................................................................................................................. 37 88

MULTI-HOMING AND LOAD BALANCING .............................................................................. 38 89

11.5.1 All-Active Redundancy Mode ................................................................................... 38 90

11.5.2 Single-Active Redundancy Mode ............................................................................. 38 91

FAST CONVERGENCE ........................................................................................................... 39 92

12 EVPN ENABLED MULTIPOINT TO MULTIPOINT ETHERNET VPN 93

SERVICES (E-LAN) ..................................................................................................................... 40 94

ETHERNET PRIVATE LAN (EP-LAN) .................................................................................. 40 95

ETHERNET VIRTUAL PRIVATE LAN (EVP-LAN) ................................................................ 41 96

EVPN FOR ESTABLISHING EP-LAN AND EVP-LAN ........................................................... 41 97

12.3.1 Service Interfaces ..................................................................................................... 42 98

12.3.2 Data plane ................................................................................................................ 43 99

12.3.3 Tunnel signaling....................................................................................................... 43 100

12.3.4 Routing ..................................................................................................................... 43 101

12.3.5 Multi-Homing and Load balancing ......................................................................... 43 102

12.3.6 OAM ......................................................................................................................... 44 103

12.3.7 Convergence ............................................................................................................ 44 104

12.3.8 PSN Resiliency ......................................................................................................... 44 105

12.3.9 Multicast and Broadcast .......................................................................................... 44 106

12.3.10 QoS ....................................................................................................................... 44 107

12.3.11 Security ................................................................................................................ 44 108

SUPPORT OF SERVICE ATTRIBUTES FOR EP-LAN AND EVP-LAN ........................................ 45 109

12.4.1 Bandwidth Profile .................................................................................................... 45 110

12.4.2 Bundling ................................................................................................................... 45 111

12.4.3 CE-VLAN ID preservation for EVC ......................................................................... 45 112

12.4.4 CE-VLAN CoS preservation for EVC ...................................................................... 46 113

12.4.5 EVC Maximum Service Frame Size ......................................................................... 46 114

12.4.6 Frame delivery ......................................................................................................... 46 115

12.4.7 Layer 2 control protocols......................................................................................... 47 116

12.4.8 EVC performance..................................................................................................... 47 117



13 EVPN ENABLED POINT TO POINT ETHERNET VPN SERVICES (E-LINE) . 49 118

ETHERNET PRIVATE LINE (EPL) .......................................................................................... 49 119

ETHERNET VIRTUAL PRIVATE LINE (EVPL) ........................................................................ 50 120

EVPN FOR ESTABLISHING EPL AND EVPL ......................................................................... 51 121


13.3.2 Operation ................................................................................................................. 52 123

13.3.3 Data Plane ............................................................................................................... 52 124

13.3.4 BGP extensions ........................................................................................................ 52 125


13.3.6 Routing ..................................................................................................................... 53 127


13.3.8 OAM ......................................................................................................................... 53 129

13.3.9 Convergence ............................................................................................................ 53 130

13.3.10 PSN Resiliency ..................................................................................................... 53 131

13.3.11 QoS ....................................................................................................................... 53 132

13.3.12 Security ................................................................................................................ 54 133

SUPPORT OF SERVICE ATTRIBUTES FOR EPL AND EVPL ...................................................... 54 134


13.4.2 Bundling ................................................................................................................... 54 136




13.4.6 Frame delivery ......................................................................................................... 56 140


13.4.8 EVC performance..................................................................................................... 56 142

13.4.9 Multiple Class of Service ......................................................................................... 57 143

14 EVPN ENABLED ROOTED-MULTIPOINT ETHERNET VPN SERVICES (E-144

TREE) 58 145

ETHERNET PRIVATE TREE (EP-TREE) .................................................................................. 58 146

ETHERNET VIRTUAL PRIVATE TREE (EVP-TREE) ................................................................ 59 147

EVPN FOR ESTABLISHING EP-TREE AND EVP-TREE ........................................................... 60 148

14.3.1 E-Tree support in EVPN .......................................................................................... 61 149


14.3.3 Data plane ................................................................................................................ 62 151


14.3.5 Routing ..................................................................................................................... 62 153


14.3.7 OAM ......................................................................................................................... 62 155

14.3.8 Convergence ............................................................................................................ 62 156

14.3.9 PSN Resiliency ......................................................................................................... 62 157

14.3.10 Multicast and Broadcast ...................................................................................... 62 158

14.3.11 QoS ....................................................................................................................... 63 159

14.3.12 Security ................................................................................................................ 63 160

SUPPORT OF SERVICE ATTRIBUTES FOR EP-TREE AND EVP-TREE ....................................... 63 161




14.4.2 Bundling ................................................................................................................... 64 163




14.4.6 Frame delivery ......................................................................................................... 65 167


14.4.8 EVC performance..................................................................................................... 65 169 170

171



List of Figures 172

173

Figure 1 Reference Architecture ...................................................................................................... 22 174

Figure 2 Components of OAM ........................................................................................................ 27 175

Figure 3 EVPN Architecture for Ethernet services using BGP MPLS ............................................ 36 176

Figure 4 Ethernet Private LAN (EP-LAN) Service ......................................................................... 40 177

Figure 5 Ethernet Virtual Private LAN (EVP-LAN) Service .......................................................... 41 178

Figure 6 Ethernet Private Line (EPL) Service ................................................................................. 50 179

Figure 7 Ethernet Virtual Private Line (EVPL) Service .................................................................. 51 180

Figure 8 Ethernet Private Tree (EP-Tree) Service ........................................................................... 59 181

Figure 9 Ethernet Virtual Private Tree (EVP-Tree) Service ............................................................ 60 182

183

184



Executive Summary 185

Carrier Ethernet provides extensions to Ethernet, enabling telecommunications network providers 186

to provide Ethernet services to customers and to utilize Ethernet technology in their networks. 187

188

Carrier Ethernet services are being used in Broadband access networks, enterprise networks and 189

backhaul networks. Providing Carrier Ethernet services using MPLS network infrastructure is 190

generating revenue opportunities for global carriers, driven by customer demand for higher 191

bandwidth connectivity. Though TR-224 describes the architecture for solutions to implement 192

Carrier Ethernet services using an MPLS network, the VPLS based solution has a number of 193

limitations when it comes to redundancy, multicast optimization and provisioning simplicity. It 194

does not address requirements such as multi-homing with all-active forwarding, load balancing, 195

policy-based control and control plane based MAC learning. Service interface requirements for 196

data-center interconnects are also not addressed by TR-224. 197

198

This document provides technical architecture and equipment requirements to implement the 199

Carrier Ethernet services using BGP MPLS-based EVPNs in order to overcome the limitations of 200

VPLS and address the additional requirements. By specifying a common technical architecture, 201

common equipment requirements and common set of feature options, this document promotes 202

multi-vendor interoperability. 203

204

205



1 Purpose and Scope 206

Purpose 207

Carrier Ethernet provides extensions to Ethernet enabling telecommunications network providers 208

to provide Ethernet services to customers and to utilize Ethernet technology in their networks. 209

Service providers are deploying Carrier Ethernet services around the globe, in large part, because 210

Carrier Ethernet has compelling capabilities such as standardized service definitions as well as 211

improved scalability, reliability, QoS, and manageability. 212

213

Carrier Ethernet services are being used in Broadband access networks, enterprise networks and 214

backhaul networks. The integration of Ethernet into MPLS network infrastructure is generating 215

revenue opportunities for global carriers, driven by customer demand for higher bandwidth 216

connectivity. This document provides a technical architecture and equipment requirements 217

implementing the specified Ethernet services using BGP MPLS-based Ethernet VPNs (EVPNs) in 218

IP/MPLS network. 219

220

New Ethernet service applications require capabilities such as: multi-homing with all-active 221

forwarding; load balancing; policy based control, and control plane MAC learning. TR-224 [4] and 222

TR-178 [2] based solutions do not provide these features; solutions based on BGP MPLS EVPNs 223

do. 224

225

By specifying a common technical architecture, common equipment requirements and common set 226

of feature options, this document promotes multi-vendor interoperability. This document may be 227

used as a basis for conformance testing. 228

Scope 229

This document defines a reference architecture for Carrier Ethernet services using BGP MPLS-230

based Ethernet VPN mechanisms: 231

232

• Ethernet multipoint to multipoint (E-LAN) 233

• Ethernet point to point (E-Line) 234

• Ethernet point to multipoint (E-Tree) including E-Tree* 235

• Ethernet access to support wholesale access service 236

• Control, OAM, QoS, reliability and scalability for the MPLS network 237

• Support Ethernet service capabilities specified in RFC 7209 [37] 238

239

This document specifies how to implement the Ethernet services layer. It does not specify the 240

service layer itself. Ethernet Control and OAM protocols will be transparently transported, except 241

for cases where Layer 2 control protocol processing is required per-service definition. 242

243

This document includes the Carrier Ethernet E-LAN, E-Line, and E-Tree (including E-Tree*) 244

services types using BGP MPLS EVPNs. 245

246



247

In order to support Carrier Ethernet services across multiple networks, the scope of this document 248

includes the following: 249

• Attachment circuits (AC) providing a user-to-network interface complying with the MEF 250

UNI are supported. 251

• Ethernet attachment circuits for multi-service broadband access and aggregation (i.e., TR-252

101/TR-178) are supported. 253

• Additional Ethernet service capabilities of BGP MPLS-based EVPNs (e.g. multi-homing 254

with all-active forwarding, load balancing, policy based control, control based MAC 255

learning, etc) are supported. 256

• Support for interworking with TR-224. 257

• To support Carrier Ethernet across multiple SP networks, the specification addresses multi 258

autonomous systems which preserves end-to-end capabilities (e.g., OAM, QoS and 259

protection etc). 260

• Cases where the UNI-N functions are or are not collocated with the PE are supported. 261

262

TR-350 provides technical architecture and equipment requirements implementing MEF Carrier 263

Ethernet services with BGP MPLS EVPNs. EVPNs architecture and protocols are based on 264

BGP/MPLS IP VPNs , which supports multiple domains. This capability is used to support 265

connectivity between service endpoints (e.g. MEF UNIs) connected to different networks or 266

operators. 267

TR-350 does not use architecture or connectivity models of Carrier Ethernet using MEF 26.1 [46]. 268

269



2 References and Terminology 270

Conventions 271

In this Technical Report, several words are used to signify the requirements of the specification. 272

These words are always capitalized. More information can be found be in RFC 2119 [8]. 273

274

MUST This word, or the term “REQUIRED”, means that the definition is an

absolute requirement of the specification.

MUST NOT This phrase means that the definition is an absolute prohibition of the

specification.

SHOULD This word, or the adjective “RECOMMENDED”, means that there

could exist valid reasons in particular circumstances to ignore this

item, but the full implications need to be understood and carefully

weighed before choosing a different course.

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" means that there

could exist valid reasons in particular circumstances when the

particular behavior is acceptable or even useful, but the full

implications need to be understood and the case carefully weighed

before implementing any behavior described with this label.

MAY This word, or the adjective “OPTIONAL”, means that this item is one

of an allowed set of alternatives. An implementation that does not

include this option MUST be prepared to inter-operate with another

implementation that does include the option.

References 275

The following references are of relevance to this Technical Report. At the time of publication, the 276

editions indicated were valid. All references are subject to revision; users of this Technical Report 277

are therefore encouraged to investigate the possibility of applying the most recent edition of the 278

references listed below. 279

A list of currently valid Broadband Forum Technical Reports is published at 280

www.broadband-forum.org. 281

282

Document Title Source Year

TR-101 Migration to Ethernet-Based Broadband

Aggregation

BBF 2011

TR-178 Multi-service Broadband Network

Architecture and Nodal Requirements

BBF 2014

TR-221 Technical Specifications for MPLS in Mobile

Backhaul Networks

BBF 2011

http://www.broadband-forum.org/

http://www.broadband-forum.org/technical/download/TR-101_Issue-2.pdf

http://www.broadband-forum.org/technical/download/TR-178.pdf




TR-224 Technical Specification for MPLS in Carrier

Ethernet Networks

BBF 2014

IEEE 802.3 IEEE Standard Ethernet IEEE 2012

IEEE 802.1Q IEEE Standard for Local and metropolitan

area networks--Media Access Control (MAC)

Bridges and Virtual Bridged Local Area

Networks

IEEE 2011

RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and

Dual Environments

IETF 1990

RFC 2119 Key words for use in RFCs to Indicate

Requirement Levels

IETF 1997

RFC 2328 OSPF Version 2 IETF 1998

RFC 3209 RSVP-TE: Extensions to RSVP for LSP

Tunnels

IETF 2001

RFC 3270 Multi-Protocol Label Switching (MPLS)

Support of Differentiated Services

IETF 2002

RFC 3473 Generalized Multi-Protocol Label Switching

(GMPLS) Signaling Resource ReserVation

Protocol-Traffic Engineering (RSVP-TE)

Extensions

IETF 2003

RFC 3478 Graceful Restart Mechanism for Label

Distribution Protocol

IETF 2003

RFC 3564 Requirements for Support of Differentiated

Services-aware MPLS Traffic Engineering

IETF 2003

RFC 3623 Graceful OSPF Restart IETF 2003

RFC 3630 Traffic Engineering (TE) Extensions to OSPF

Version 2

IETF 2003

RFC 5306 Restart Signaling for Intermediate System to

Intermediate System (IS-IS)

IETF 2004

RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP

Tunnels

IETF 2005

RFC 4124 Protocol Extensions for Support of Diffserv-

aware MPLS Traffic Engineering

IETF 2005

RFC 4206 Label Switched Paths (LSP) Hierarchy with

Generalized Multi-Protocol Label Switching

(GMPLS) Traffic Engineering (TE)

IETF 2005

RFC 4364 BGP/MPLS IP Virtual Private Networks

(VPNs)

IETF 2006


http://standards.ieee.org/about/get/802/802.3.html

http://standards.ieee.org/getieee802/download/802.1Q-2011.pdf

http://www.ietf.org/rfc/rfc1195.txt

















RFC 4379 Detecting Multi-Protocol Label Switched

(MPLS) Data Plane Failures

IETF 2006

RFC 4761 Virtual Private LAN Service (VPLS) Using

BGP for Auto-Discovery and Signaling

IETF 2007

RFC 4762 Virtual Private LAN Service (VPLS) Using

BGP for Auto-Discovery and Signaling

IETF 2007

RFC 5036 LDP Specification IETF 2007

RFC 5150 Label Switched Path Stitching with

Generalized Multiprotocol Label Switching

Traffic Engineering (GMPLS TE)

IETF 2008

RFC 5151 Inter-Domain MPLS and GMPLS Traffic

Engineering -- Resource Reservation

Protocol-Traffic Engineering (RSVP-TE)

Extensions

IETF 2008

RFC 5283 LDP Extension for Inter-Area Label Switched

Paths (LSPs)

IETF 2008

RFC 5286 Basic Specification for IP Fast Reroute:

Loop-Free Alternates

IETF 2008

RFC 5305 IS-IS Extensions for Traffic Engineering IETF 2008

RFC 5586 MPLS Generic Associated Channel IEIF 2009

RFC 5880 Bidirectional Forwarding Detection (BFD) IETF 2010

RFC 5881 Bidirectional Forwarding Detection (BFD)

for IPv4 and IPv6 (Single Hop)

IETF 2010

RFC 5884 Bidirectional Forwarding Detection (BFD)

for MPLS Label Switched Paths (LSPs)

IETF 2010

RFC 6424 Mechanism for Performing Label Switched

Path Ping (LSP Ping) over MPLS Tunnels

IETF 2011

RFC 6790 The Use of Entropy Labels in MPLS

Forwarding

IETF 2012

RFC 7209 Requirements for Ethernet VPN (EVPN) IETF 2014

RFC 7387 Framework for Ethernet Tree (E-Tree)

Service over a Multiprotocol Label Switching

(MPLS) Network

IETF 2014

RFC 7432 BGP MPLS Based Ethernet VPN IETF 2015

G.8013/Y.1731 OAM functions and mechanisms for Ethernet

based networks

ITU-T 2013

MEF 6.1 Ethernet Services Definitions - Phase 2 MEF 2008

















https://tools.ietf.org/rfc/rfc7432.txt

https://www.itu.int/rec/T-REC-G.8013-201311-I/en

http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF6-1.pdf



MEF 10.2 Ethernet Services Attributes - Phase 2 MEF 2009

MEF 30 Service OAM Fault Management

Implementation Agreement

MEF 2011

MEF 22.1 Mobile Backhaul Phase 2 Implementation

Agreement

MEF 2012

MEF 23.1 Carrier Ethernet Class of Service – Phase 2 MEF 2012

MEF 26.1 External Network Network Interface (ENNI) –

Phase 2

MEF 2012

MEF 35 Service OAM Performance Monitoring

Implementation Agreement

MEF 2012

MEF 6.1.1 Layer 2 Control Protocol Handling

Amendment to MEF 6.1

MEF 2012

MEF 10.3 Ethernet Services Attributes - Phase 3 MEF 2013

MEF 6.2 EVC Ethernet Services Definitions - Phase 3 MEF 2014

MEF 45 Multi-CEN L2CP MEF 2014

draft-ietf-bess-

evpn-etree

E-TREE Support in EVPN & PBB-EVPN IETF 2017

draft-ietf-bess-

evpn-vpws

Virtual Private Wire Support in EVPN IETF 2017

Definitions 283

The following terminology is used throughout this Technical Report. 284

285

AGN An aggregation node (AGN) is a node which aggregates several access nodes

(ANs).

AN An access node is a node which processes customer frames or packets at

Layer 2 or above. This includes but is not limited to DSLAMs or OLTs (in

case of (G)PON deployments).

E-Line A service connecting two customer Ethernet ports over a WAN.

E-LAN A multipoint service connecting a set of customer endpoints, giving the

appearance to the customer of a bridged Ethernet network connecting the

sites.

E-Tree A rooted multipoint Ethernet Virtual Connection. The E-Tree service type

can support one or multiple Root UNIs (see Section 9.3/MEF 6.2 [50])

http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF10.2.pdf

http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF_30.pdf

http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF_22.1.pdf



http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF_35.pdf

http://www.metroethernetforum.org/PDF_Documents/technical-specifications/MEF_6.1.1.pdf



http://www.metroethernetforum.org/Assets/Technical_Specifications/PDF/MEF_45.pdf

https://tools.ietf.org/html/draft-ietf-bess-evpn-etree

https://tools.ietf.org/html/draft-ietf-bess-evpn-etree

http://tools.ietf.org/html/draft-ietf-bess-evpn-vpws

http://tools.ietf.org/html/draft-ietf-bess-evpn-vpws



E-Tree* Partially implementing MEF multipoint service connecting only one root and

a set of leaves, but preventing inter-leaf communication. See details in TR-

221.

Note: Ethernet Tree (E-Tree) service type is specified in Section 6.3/MEF 6.1

[41]. The Appendix in TR-221 modifies the E-Tree service type which is

used in different services. The modified E-Tree* service type is used in both

Ethernet Private Tree service and Ethernet Virtual Private Tree Service

specified in Section 14 .

Abbreviations 286

This Technical Report uses the following abbreviations: 287

288

AC Attachment Circuit

AGN Aggregation Node

AN Access Node

BFD Bidirectional Forwarding Detection

BGP Border Gateway Protocol

BNG Broadband Network Gateway

CE Customer Edge

CoS Class of Service

CV Connectivity Verification

EPL Ethernet Private Line

EP-LAN Ethernet Private-LAN

EVC Ethernet Virtual Connection

EVPL Ethernet Virtual Private Line

EVP-LAN Ethernet Virtual Private – LAN

FD Frame Delay

FRR Fast Re-route

FLR Frame Loss Ratio

H-VPLS Hierarchal Virtual Private LAN Service

IETF Internet Engineering Task Force

IP Internet Protocol

ITU-T International Telecommunication Union Telecommunication Standardization

Sector

L2VPN Layer 2 Virtual Private Network

LAN Local Area Network

LER Label Edge Router

LFA Loop Free Alternate

LSP Label Switched Path



LSR Label Switch Router

MAC Medium Access Control

MEF Metro Ethernet Forum

MPLS Multi Protocol Label Switching

OAM Operations, Administration and Management

OAMPDU OAM Protocol Data Unit

P Provider

PE Provider Edge

PSN Packet Switched Network

PW Pseudowire

QoS Quality of Service

RFC Request for Comments

RSVP-TE Resource ReSerVation Protocol with Traffic Engineering extensions

SLA Service Level Agreement

TE Traffic Engineering

T-LDP Targeted Label Distribution Protocol

TLV Type/Length/Value

TR Technical Report

UNI User to Network Interface

UDP User Datagram Protocol

VPLS Virtual Private LAN Service

VPN Virtual Private Network

VPWS Virtual Private Wire Service

WG Working Group

289

290



3 Technical Report Impact 291

Energy Efficiency 292

TR-350 has no impact on energy efficiency. 293

IPv6 294

Carrier Ethernet services operate at Layer 2 and therefore the network is agnostic to IPv6 user 295

traffic. The IPv6 header DSCP field is assumed to be mapped to the Ethernet P bits by the service 296

user. 297

298

IPv6 addressing may appear in its respective places in control, OAM, and management protocols, 299

e.g., node ids, FECs, and loopback addresses, etc. 300

301

TR-350 has no direct impact on IPv6. 302

Security 303

Security requirements are specified for each service in respective sections. 304

Privacy 305

Any issues regarding privacy are not affected by TR-350. 306

307

308



4 Carrier Ethernet services 309

Ethernet is now being used as both a transport technology and a service delivery architecture. The 310

MEF Carrier Ethernet specifies Ethernet service type, service attributes, QoS and SLA. The 311

service type includes point-to-point (E-Line), point-to-multipoint (E-Tree), multipoint-to-312

multipoint (E-LAN), and E-Access. The service definition includes both port-based and VLAN-313

based service identification. 314

315

TR-224 refers to MEF 6.1 and MEF 10.2. TR-350 uses the backward compatible subset of the 316

revised specifications MEF 6.2 [50] and MEF 10.3 [49] to achieve the equivalent function. This 317

makes WT-350 compatible with TR-224. 318

319

The MEF also defined Carrier Ethernet as a ubiquitous, standardized, carrier-class service and 320

network defined by attributes that distinguish Carrier Ethernet from familiar LAN-based Ethernet. 321

Carrier Ethernet Requirements 322

Service providers worldwide are migrating their existing networks to deliver Carrier Ethernet 323

services to enterprises, businesses & residential end-users. The attributes are as follows: 324

325

1. Standardized Services 326

• Support E-Line, E-LAN and E-Tree service types as defined by MEF 327

• No changes to customer LAN equipment or networks and accommodates existing 328

network connectivity such as, time-sensitive, TDM traffic and signaling 329

• Wide choice and granularity of bandwidth and quality of service options 330

2. Security 331

3. Scalability 332

• The ability to support millions of Ethernet Virtual Connection (EVC) services for 333

enterprise and residential users 334

• Scalability of bandwidth from 1 Mbps to 10 Gbps and beyond, in granular 335

increments 336

4. Reliability 337

• The ability for the network to detect & recover from faults quickly 338

• Fast network convergence 339

5. Quality of Service 340

• Service Level Agreements (SLAs) that deliver end-to-end performance 341

• Traffic profile enforcement per-EVC 342

• Hierarchical queuing 343

6. Service Management 344

• Minimize network touch points in provisioning 345

• Standards-based OAM to support SLA 346

347

348



5 Layer 2 Ethernet VPNs in MPLS Networks 349

MPLS has for a long time been defined as a convergence technology, one that will allow service 350

providers to bring together their disparate networks and leverage features like traffic engineering, 351

hierarchal QoS, and service interworking. 352

353

Provider Provisioned Virtual Private Networks (PPVPN) now dominates the IP-VPN services 354

market and is projected for significant growth. Many service providers have provided Ethernet 355

VPN services using Virtual Private LAN Services (VPLS) as an alternative that allows enterprises 356

to manage their own routing. 357

358

TR-224 uses VPLS to support Ethernet LAN services in IP/MPLS networks. A VPLS PE 359

emulates an Ethernet bridge (IEEE 802.1Q [6]) and performs MAC learning in the data plane. 360

New applications using Ethernet services require capabilities such as: multi-homing with all-active 361

forwarding, load balancing, policy based control, and control plane MAC learning. To support 362

these capabilities IETF developed BGP MPLS-based Ethernet VPNs (EVPNs). TR-224 based 363

solutions do not provide these features. 364

365

When an Ethernet multipoint service is provided using EVPN, control-plane-based remote MAC 366

learning is used over the MPLS core (PE to PE) network. MAC learning between PE and CE is 367

done in the data plane. EVPN is designed to handle multi-homing, and per-flow load balancing. 368

The EVPN technology uses MP-BGP over an MPLS network. The technology is similar to BGP 369

MPLS-based IP VPNs (RFC 4364). Using MP-BGP to distribute the reachability of MAC 370

addresses over a MPLS network brings the same operational control and scale of L3VPN to 371

L2VPN. 372

373

The EVPN solution provides a common base for all Ethernet service types including E-LAN, E-374

Line, E-Tree (including E-Tree* from TR-221), E-Access and enables these services to be created 375

such that they can span across domains. In addition to the common base above, BGP MPLS-based 376

EVPNs also provide solutions for the requirements in RFC 7209 [37] including: 377

• Multi-homing: with all active forwarding and load balancing from CE to CE. VPLS can 378

only support multi-homing with single active mode. 379

• Flow based load balancing and multipath 380

• Multicast optimization: must be able to support P2MP MPLS LSPs and MP2MP MPLS 381

LSPs. VPLS only supports P2MP MPLS LSPs. 382

• Fast convergence to minimize downtime and packet loss. 383

• Support MAC mobility to support cloud services. 384

385

386



6 Reference Architecture 387

General Reference Architecture 388

Figure 1 provides a generic overview of how Carrier Ethernet Services can be deployed using a 389

BGP MPLS-based EVPN infrastructure, including basic reference points and their functional roles. 390

Depending on the application, non-MEF-defined Ethernet Attachment Circuits and Attachment 391

Circuits providing User-to-Network interfaces complying with Metro Ethernet Forum definitions 392

(MEF UNI) are supported. Multi-domain connectivity and external handoff are also supported. 393

394

395 Figure 1 Reference Architecture 396

397

Defined as business interfaces supporting the service handoff between different parties (between 398

user and provider or between providers, respectively), UNI has two functions: 399

400

1. provide reference points for network demarcation 401

2. provide associated functionality 402

403

For deploying Metro Ethernet Forum-compliant Ethernet Services over MPLS, PE nodes need to 404

support the corresponding MEF UNI functionality at Attachment Circuit interfaces. 405

406

407

408

409

410

411

412



MPLS for Carrier Ethernet in Broadband Access & Aggregation 413

6.2.1 Multi-Service Broadband Access & Aggregation 414

For Multi-Service Broadband access and aggregation architecture see Section 6.2.1/TR-224 [4]. 415

6.2.2 TR-178 Architectures 416

There are two reference architectures that are being used to represent TR-178 networks: 1) MPLS-417

enabled access and 2) TR-101. For architectural details of MPLS-enabled access nodes and TR-418

101 see Section 6.2.2/TR-224 [4]. 419

420



7 Signaling and Routing 421

This section specifies the signaling protocol used to establish the underlying MPLS tunnel. Traffic 422

engineered PSN tunnels must be used when specific path (e.g. for protection purpose), QoS or 423

bandwidth constraints are required. 424

LSP Signaling 425

One of the following provisioning and signaling procedures are used for LSPs. 426

427

[R-1] PE and P routers supporting MPLS TE and non-TE LSPs MUST support one or 428

both of the following methods: 429

• Static provisioning 430

• Dynamic signaling 431

432

[R-2] Both of the following methods MUST be supported by PE and P routers for 433

dynamically signaled PSN tunnel LSPs: 434

• LDP is used to set up, maintain and release LSP tunnels per RFC 5036 [25]. 435

• RSVP-TE is used to set up, maintain and release LSPs for traffic engineered tunnels per 436

RFC 3209 [10] and RFC 5151 [27]. When traffic engineering is needed on the LSP, 437

RSVP-TE MUST be used. 438

439

[R-3] When co-routed bidirectional LSPs are required, GMPLS-RSVP-TE as per RFC 440

3473 [12] MAY be supported by PE and P routers. 441

7.1.1 Multi-area LSP Signaling 442

Several operators have multi-area networks for scalability. Link state Interior Gateway Protocols 443

(IGPs) such as OSPF (RFC 2328 [9]) and IS-IS (RFC 1195 [7]) allow dividing networks into areas 444

or levels so as to increase routing scalability within a routing domain. 445

446

Further some operators’ L2VPN networks span different geographical areas. To support these 447

networks, it is necessary to support inter-area and inter-AS (Autonomous System) Multiprotocol 448

Label Switching (MPLS) LSPs. 449

450

An “MPLS Domain” is considered to be any collection of network elements implementing MPLS 451

within a common realm of address space or path computation responsibility. Examples of such 452

domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and 453

GMPLS overlay networks. 454

455

Signaling extensions for inter-area LSPs (that is, LSPs that traverse at least two IGP areas) are 456

required to ensure MPLS connectivity between PEs located in distinct IGP areas. 457

458

459

460



461

Multi-area RSVP-TE Signaling 462

Inter-domain TE LSPs can be supported by one of three options as specified in RFC 5151 [27] and 463

given below: 464

• contiguous LSPs 465

• nested LSPs 466

• stitched LSPs. 467

Note: While the specifications below cover both MPLS Traffic Engineering (TE) 468

and GMPLS, the intent is to use the TE coverage. 469

Contiguous 470

A contiguous TE LSP is a single TE LSP that is set up across multiple 471

domains using RSVP-TE signaling procedures described in Section 7.1. 472

473

Nested 474

One or more TE LSPs may be nested within another TE LSP as described in 475

RFC 4206 [20]. This technique can be used to nest one or more inter-476

domain TE LSPs into an intra-domain hierarchical LSP (H-LSP). The label 477

stacking construct is used to achieve nesting in packet networks. 478

479

To improve scalability, it may be useful to aggregate LSPs by creating a 480

hierarchy of such LSPs. 481

482

[R-4] PE routers SHOULD support establishment of RSVP-TE LSPs using 483

LSP hierarchy as per RFC 4206 [20]. 484

485

Stitched 486

LSP stitching signaling procedures are described in RFC 5150 [26]. This 487

technique can be used to stitch together shorter LSPs (LSP segments) to 488

create a single, longer LSP. The LSP segments of an inter-domain LSP may 489

be intra-domain LSPs or inter-domain LSPs. 490

491

The process of stitching LSP segments results in a single, end-to-end 492

contiguous LSP in the data plane. But in the control plane, each segment is 493

signaled as a separate LSP (with distinct RSVP sessions) and the end-to-end 494

LSP is signaled as yet another LSP with its own RSVP session. Thus, the 495

control plane operation for LSP stitching is very similar to that for nesting. 496

497



[R-5] PE routers SHOULD support establishment of RSVP-TE LSPs using 498

LSP stitching as per RFC 5150 [26]. 499

Multi-area LDP Signaling 500

RFC 5283 [28] facilitates the establishment of Label Switched Paths (LSPs) that would span 501

multiple IGP areas in a given Autonomous System (AS). 502

503

[R-6] PE routers SHOULD support establishment of inter-area LSPs using 504

LDP as per RFC 5283 [28]. 505

Routing 506

[R-7] One or both of the following methods MUST be supported by PE and P routers: 507

• Static routing 508

• Dynamic routing 509

510

[R-8] Both of the following methods MUST be supported by PE and P routers to 511

exchange routing information to facilitate dynamic LSP signaling: 512

• OSPF (RFC 2328 [9]) 513

• IS-IS (RFC 1195 [7]) 514

515

[R-9] Traffic engineering extensions of OSPF and IS-IS are used to exchange traffic 516

attributes for RSVP-TE tunnels. If TE is supported, both of the following methods MUST 517

be supported by PE and P routers: 518

• OSPF-TE (RFC 3630 [16]) 519

• IS-IS-TE (RFC 5305 [30]) 520



8 OAM 521

OAM in Carrier Ethernet networks was developed to provide fault management and performance 522

monitoring tools for network links and end-to-end EVCs. Figure 2 below shows the components 523

of OAM when the MEF services are provided using EVPN. 524

525

526 527

Figure 2 Components of OAM 528

529

Ethernet OAM 530

The OAM functions for the UNI should use the Ethernet OAM as defined in Link OAM (Clause 531

57/IEEE 802.3 [5]) and/or ITU-T G.8013/Y.1731 [40]. 532

8.1.1 Link OAM 533

The PE supports Ethernet Link OAM, when the user is directly connected to the network 534

demarcation point (i.e., at the MEF UNI in Figure 2). Link OAM provides OAM functions for 535



network access segments (UNI-C to UNI-N). Link OAM provides for Ethernet Link Fault 536

Detection, Monitoring and Loopback for access links. 537

538

[R-10] The PE MUST support link OAM Active mode as per Clause 57.2.9.1/IEEE 802.3 539

[5]. 540

541

[R-11] The PE MUST support initiating OAM Discovery process as per Subclause 542

57.3.2.1/IEEE 802.3 [5]. 543

544

[R-12] The PE MUST support sending informational OAM Protocol Data Units 545

(OAMPDU) as per Subclause 57.2.10/IEEE 802.3 [5]. 546

547

[R-13] The PE MUST support sending Event Notification OAMPDUs as per Subclause 548

57.2.10/IEEE 802.3 [5]. 549

550

[R-14] The PE MUST support sending loopback control OAMPDUs as per Subclause 551

5.2.11/IEEE 802.3 [5]. 552

553

[R-15] The PE MAY support sending Organization specific OAMPDU per Subclause 554

57/IEEE 802.3 [5]. 555

556

[R-16] The PE MAY support sending Variable Request OAMPDUs as per Subclause 557

57.4.3.3/IEEE 802.3 [5]. 558

8.1.2 ITU-T G.8013/Y.1731 559

The OAM functions defined in ITU-T G.8013/Y.1731 can be used for OAM of the UNI between 560

the CE and the PE. 561

562

[R-17] The PE MUST support sending and receiving OAM frames at level 0 (as 563

recommended in G.8013/Y.1731 [40]). 564

MEF Service OAM 565

The Carrier Ethernet Services are provided between one User Network Interface (UNI) and one or 566

more UNIs. A network operator must be able to manage the services using Service OAM 567

(SOAM). The network operator’s service OAM is originated at the PE’s UNI-N. 568

569

[R-18] The PE MUST support SOAM at the EVC SOAM level 4 as described in MEF 30 570

[43]. 571

572

[R-19] OAM frames, sent at SOAM levels 5, 6, or 7, as described in MEF 30, are sent as 573

user data and MUST be carried transparently. 574

575

[R-20] The PE MAY support sending and receiving SOAM frames across the UNI at the 576

UNI SOAM level 1, as described in MEF 30 [43]. 577



See Section 12.4.8 for information on performance monitoring. 578

MPLS OAM 579

This section describes techniques to perform OAM for the underlying MPLS tunnels used to 580

support Ethernet services. OAM is an important and fundamental functionality in an MPLS 581

network. OAM contributes to the reduction of operational complexity, by allowing for efficient 582

and automatic detection, localization, handling and diagnosis of defects. OAM functions, in 583

general, are used for fault-management, performance monitoring, and protection-switching 584

applications. 585

8.3.1 LSP OAM 586

This section describes techniques to perform OAM for the underlying MPLS LSPs used in an 587

EVPN application. 588

589

LSP-Ping and Bidirectional Forwarding Detection (BFD) RFC 5880 [32] are OAM mechanisms 590

for MPLS LSPs RFC 5884 [34]. Further it is desirable that the OAM traffic is sent in-band in an 591

LSP. The following OAM mechanisms are supported: 592

593

[R-21] The PE MAY support GAL and G-ACh per LSP, as per RFC 5586 [31]. 594

BFD for MPLS LSPs 595

BFD monitors the integrity of the LSP for any loss of continuity defect. In particular, it can be 596

used to detect a data plane failure in the forwarding path of an MPLS LSP. 597

598

[R-22] PE and P routers MUST support BFD for MPLS LSPs as per RFC 599

5884 [34]. 600

Detecting MPLS Data Plane Failures 601

LSP Ping is used to perform on-demand Connectivity Verification (CV) and Route Tracing 602

functions. It provides two modes: “ping” mode and “traceroute” mode. 603

In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which 604

point it is sent to the control plane of the egress LSR, which then verifies whether it is indeed an 605

egress for the FEC. 606

607

[R-23] PE and P routers MUST support “ping” mode as per RFC 4379 [22]. 608

609

RFC 6424 [35] enhances the mechanism for performing Label Switched Path Ping (LSP Ping) 610

over MPLS Tunnels and when LSP stitching [RFC5150] is in use. 611

612

[R-24] PE and P routers MUST support enhanced MPLS ping and traceroute as per RFC 613

6424 [35]. 614

615



In "traceroute" mode (fault isolation), the packet is sent to the control plane of each transit LSR, 616

which performs various checks that it is indeed a transit LSR for this path; this LSR also returns 617

further information that helps check the control plane against the data plane. 618

619

[R-25] PE and P routers SHOULD support “traceroute” mode as per RFC 4379 [22]. 620

621

The LSP Ping Reply modes as defined in Section 3/RFC 4379 [22] apply as shown in 622

Table 1. 623

624

625

Reply Mode Echo request Echo Reply

Reply via an IPv4/IPv6 UDP packet (code value 2) MUST MUST

Reply via application level control channel (code value 4) MAY MAY

626

Table 1 LSP Ping Reply Modes 627

628

The following subsections of Section 3.2/RFC 4379 [22] concerning Target FEC Stack apply as 629

follows: 630

631

[R-26] When LDP is supported - LDP IPv4 prefix as defined in Section 3.2.1/RFC 4379 632

[22] MUST be supported. 633

634

[R-27] When RSVP is supported - RSVP IPv4 LSP as defined in Section 3.2.3/RFC 4379 635

[22] MUST be supported. 636

637

[R-28] When BGP is supported – BGP-labeled IPv4 prefix as defined in Section 638

3.2.11/RFC 4379 [22] MUST be supported. 639

640

[R-29] When LDP is supported - LDP IPv6 prefix as defined in Section 3.2.2/RFC 4379 641

[22] SHOULD be supported. 642

643

[R-30] When RSVP is supported - RSVP IPv6 LSP as defined in Section 3.2.4/RFC 4379 644

[22] SHOULD be supported. 645

646

[R-31] When BGP is supported – BGP-labeled IPv6 prefix as defined in Section 647

3.2.12/RFC 4379 [22] SHOULD be supported. 648

8.3.2 Convergence 649

This section specifies the requirements for the recovery mechanisms from PE to CE network (AC 650

link) failures. The recovery procedures are described in Section 17/RFC 7432 [39]. 651

652

[R-32] The PE routers MUST support recovery from PE to CE network failures (AC link 653

failures) as per Section 17.3/RFC 7432 [39]. 654

655



[R-33] The PE routers MUST support recovery from PE failures as per Section 17.2/RFC 656

7432 [39]. 657

658

659



9 QoS 660

The MPLS network supporting the Carrier Ethernet services has to provide QoS and service level 661

agreements. The QoS capabilities must be end-to-end, which includes both ACs and MPLS 662

domains. Usually an MPLS network will support guaranteeing sufficient bandwidth if available to 663

support new and existing Carrier Ethernet connections conforming to all SLA metrics including 664

protection mechanisms. 665

666

DiffServ-TE classes of service is used to support MEF 23.1 [45] “CoS Labels” to achieve a 667

particular level of performance. MPLS DiffServ-TE enables the advantages of both DiffServ and 668

TE. The DiffServ-TE requirement is to make separate bandwidth reservations for different classes 669

of traffic. RFC 3564 [14] provides the concept of a class type (CT). 670

671

The following capabilities are to be supported by the PEs: 672

673

[R-34] The PE MUST support at least 4 CoS and associated service metrics (e.g. delay, 674

delay variation, packet loss) as defined in MEF 22.1 [44] “EVC Requirements”. 675

676

[R-35] The PE SHOULD support Connection Admission Control to guarantee sufficient 677

bandwidth is available to support new connection conforming to all SLA metrics defined in 678

MEF 10.2 [42]. 679

680

[R-36] The PE SHOULD support Differentiated Service aware MPLS traffic engineering 681

as per RFC 4124 [19]. 682

683

[R-37] The ingress PE MUST map the PCP (in the PRI field of the 802.1Q VLAN tag 684

IEEE 802.1Q [6]) into the TC field of the MPLS label stack. 685

Tunnel CoS mapping and marking 686

Two types of LSPs are defined in RFC 3270 [11]: 687

688

[R-38] The PE and P routers MUST support E-LSP as per Section 1.2/RFC 3270 [11]: 689

LSPs which can transport multiple Ordered Aggregates, so that the TC field of the MPLS 690

Shim Header conveys to the LSR the PHB to be applied to the packet (covering both 691

information about the packet's scheduling treatment and its drop precedence). 692

693

[R-39] The PE and P routers MAY support L-LSP as per Section 1.3/RFC 3270 [11]: LSPs 694

which only transport a single Ordered Aggregate, so that the packet's scheduling treatment 695

is inferred by the LSR exclusively from the packet's label value while the packet's drop 696

precedence is conveyed in the TC field of the MPLS Shim Header. 697

698

[R-40] The PE MUST support COS marking in the TC bits of the LSP labels. 699

700

[R-41] The PE MUST support the Pipe model as per RFC 3270 [11]. 701

702

703



10 PSN resiliency 704

In EVPN, the PEs are connected over an underlying PSN infrastructure. For EVPN resiliency, the 705

PSN must necessarily be resilient. When the PEs are connected by an MPLS infrastructure then 706

the resiliency mechanisms in MPLS such as fast reroute (FRR) are required. This section lists the 707

resiliency requirements for MPLS. If the MPLS infrastructure is run over another layer (e.g. a L1 708

network) the resiliency requirements of the other layers are considered to be outside the scope of 709

this section. When resiliency mechanisms are available at multiple layers the resiliency 710

mechanism at a layer must be triggered only after a sufficient delay to let the resiliency mechanism 711

of the underlying layer to take effect. 712

713

MPLS resiliency requires failure detection mechanisms and LSP recovery mechanisms. To speed 714

up total recovery time, local-repair mechanisms with pre-computed, pre-established 715

alternate/backup paths should be used whenever possible. Section 10.1 lists the failure detection 716

requirements and Section 10.2 lists the requirements for LSP recovery. 717

718

MPLS resiliency is also affected by the restart of control-plane protocols. The MPLS requirements 719

to support resiliency of control protocols are listed in Section 10.3. 720

Failure detection 721

The failure detection mechanism that triggers the recovery mechanisms should have a low failure 722

detection time and also a low overhead. In order for the deployment to allow a choice of routing 723

protocols, the failure detection mechanism should be independent of specific routing protocols. 724

The Bidirectional Forwarding Detection (BFD) protocol specified in RFC 5880 [32] provides such 725

a mechanism. For MPLS LSP BFD requirements see Section 8.3.1. 726

727

[R-42] The PE and P routers MUST support BFD for single hops as per RFC 5881 [33] 728

LSP recovery 729

The LSP recovery mechanism should support local repair mechanisms with pre-computed and pre-730

established alternate/backup paths for both RSVP-TE RFC 3209 [10] and LDP RFC 5036 [25] 731

signaled LSPs. Recovery from different types of failure such as link, node, etc. should be 732

supported. 733

734

[R-43] The PE and P routers MUST support the facility backup method of doing fast 735

reroute (FRR) for RSVP-TE LSP Tunnels as per RFC 4090 [18]. 736

737

[R-44] The PE and P routers SHOULD support the one-to-one backup method of doing 738

fast reroute (FRR) for RSVP-TE LSP Tunnels as per RFC 4090 [18]. 739

740

[R-45] The PE and P routers MUST support the loop-free alternates (LFA) method of FRR 741

for LDP LSPs as per RFC 5286 [29] as well as support LFA FRR for the IGP on whose 742

routes LDP depends. 743

744



Control plane resiliency 745

To prevent LSPs from going down due to control-plane protocols restart, the graceful restart 746

control-plane resiliency mechanism is required. 747

748

[R-46] The PE and P routers MUST support RSVP-TE graceful restart as specified in 749

Section 9/RFC 3473 [12] as well as graceful restart for the routing protocols on which 750

RSVP-TE path computation depends. 751

752

[R-47] The PE and P routers MUST support LDP graceful restart as specified in RFC 3478 753

[13] as well as graceful restart for the routing protocols on whose routes LDP depends. 754

755

[R-48] The PE and P routers SHOULD support OSPF graceful restart as specified in RFC 756

3623 [15]. 757

758

[R-49] The PE and P routers SHOULD support IS-IS graceful restart as specified in RFC 759

5306 [17]. 760

761

762



11 BGP MPLS-Based Ethernet VPN 763

This section covers the generic BGP MPLS-based Ethernet VPN requirements. Specific 764

requirements such as multicast that are applicable to a subset of Ethernet VPN services (e.g. EP-765

LAN, EVP-LAN, etc) are covered in subsequent sections. 766

767

EVPN overcomes the limitations of current E-Line and E-LAN services supported by VPLS (RFC 768

4761 [23], RFC 4762[24]) and VPWS. EVPN provides flexible multi-homing with all-active 769

redundancy mode, MAC learning using control plane, multicast optimization, provisioning 770

simplicity and network resiliency between edge nodes. 771

772

The EVPN specification supports several ways for PE nodes to connect, but this TR only supports 773

use of MPLS, which enable easy interworking with TR-224 [4] based Ethernet services. 774

Reference Architecture and Overview 775

Figure 3 describes EVPN for the next-generation of Ethernet services. An EVPN instance 776

comprises of CEs connected to PEs, which are part of the MPLS network. The PEs provide virtual 777

Layer 2 bridge connectivity between CEs. The PEs are connected by an underlying MPLS 778

network that provides QoS and resiliency. 779

780

Unlike VPLS, which uses only data-plane based MAC learning, EVPN uses the control plane 781

based MAC learning for remote MACs. EVPN uses MP-BGP to distribute MAC routes and 782

allows fine-grained control over MAC route distribution. 783

784

EVPN instance (EVI) is an EVPN routing and forwarding instance on a PE. If a CE is multi-785

homed to two or more PEs, the set of Ethernet links constitute an Ethernet Segment (ES). Each 786

Ethernet Segment is identified using a unique Ethernet Segment identifier (ESI). For additional 787

details see RFC 7432 [39]. 788

789



790

791 Figure 3 EVPN Architecture for Ethernet services using BGP MPLS 792

793

EVPN Service Interfaces 794

EVPN defines several types of service interfaces. See Section 6/RFC 7432 [39] for details. These 795

service interfaces are consistent with MEF-defined services and provide easy migration to EVPN 796

infrastructure for even richer service offerings. The various types of service interfaces include 797

mapping of specific VLANs or their bundles and even allow service awareness when they are 798

mapped to EVPN instances. The requirements for the support of various service interfaces are 799

specified in the subsections of the respective services. 800

11.2.1 VLAN-Based Service Interfaces 801

This service interface supports a single broadcast domain or VLAN per-EVPN instance. 802

This service interface can be used to support E-LAN or E-Line for a single broadcast domain with 803

customer VLANs having local significance. Ethernet frames transported over an MPLS network 804

remain tagged with the originating VID. VID translation can be performed on the destination PE. 805

806

11.2.2 VLAN Bundle Service Interfaces 807

This service interface supports a bundle of VLAN over one EVPN instance. Multiple VLANs 808

share the same bridge. It supports an N:1 mapping between VLAN ID and MAC-VRF. This 809

service interface requires that MAC addresses are unique across VLANs of the EVI and VID 810

translation is not allowed. 811

812

This service interface also supports a special case known as a port-based VLAN Bundle service 813

interface, where all the VLANs on a port are part of the same service and map to the same bundle. 814



11.2.3 VLAN-Aware Bundle Service Interfaces 815

This service interface is an additional service interface defined in EVPN that is not supported by 816

TR-224 or VPLS. It provides customers with a single E-LAN service for multiple broadcast 817

domains. With this service interface, an EVPN instance consists of multiple broadcast domains or 818

VLANs, with each VLAN having its own bridge domain. Like the VLAN bundle service 819

interface, this interface supports N:1 mapping between VLAN ID and EVI. Since bridge domains 820

are separate, it allows for local VID translation. 821

822

This service interface also supports a special case known as a port-based VLAN-Aware bundle 823

service interface, where all the VLANs on a port are part of the same service and map to the same 824

bundle. 825

Data Plane 826

11.3.1 Underlying PSN transport 827

[R-50] The PEs MUST support MPLS as the underlying PSN transport as specified in 828

Section 4/RFC 7432 [39]. 829

11.3.2 VPN encapsulation 830

To distinguish packets received over the PSN destined to different EVPN instances, MPLS labels 831

must be used as described in Section 4/RFC 7432 [39]. The specific data plane operations 832

applicable to a service are specified in the subsections of the respective service. 833

11.3.3 VID Translation 834

[R-51] The PEs MUST support VID translation for packets received from the PSN and sent 835

to the CE, when supporting service interfaces as specified in Section 6/RFC 7432 [39]. 836

11.3.4 Frame Ordering 837

Section 18/RFC 7432 specifies frame ordering. In order to avoid misordering, it is recommended 838

that P routers not use deep packet inspection to do ECMP. 839

840

[R-52] The P routers SHOULD NOT do deep packet inspection for ECMP. RFC 6790 [36] 841

specifies techniques so that P routers do effective load balancing without the need for deep 842

packet inspection. 843

844

Control Plane 845



The EVPN PEs signal and learn MAC address over the control plane. RFC 7432 adds BGP 846

extended communities, which allow PE routers to advertise and learn MAC addresses and Ethernet 847

segments. This is one of the major differences with the VPLS solution, which relies on data-plane 848

learning. EVPN added four Route types and communities. For additional details see RFC 7432 849

[39]. 850

851

[R-53] The PEs MUST support MP-BGP as a control protocol for EVPN as specified in 852

Section 4 and 7/RFC 7432 [39]. 853

854

Note: The detailed control protocol requirements of MP-BGP are specified in the 855

subsections of the respective services. 856

857

With MPLS data plane, BGP routes also signal the MPLS labels associated with MAC addresses 858

and Ethernet segments. This separates EVPN from a VPLS solution. EVPNs do not use 859

Pseudowires. 860

Multi-Homing and Load balancing 861

Due to rapid increase of data traffic, running the network in active/standby mode can be 862

inefficient. In addition to better link utilization, multi-homed connections also offer greater 863

resiliency and reliability against the failure of one connection or node. Multi-homing includes the 864

ability of establishing multiple connections between PEs and to load-balance across those 865

connections. For additional details on multi-homing see Section 8/RFC 7432 [39]. EVPNs 866

supports both single-active and all-active multi-homing with load balancing. VPLS only supports 867

single-active multi-homing. 868

869

With support for both all-active per-service and all-active per-flow multi-homing, EVPNs enables 870

better load balancing across peering PEs as compared to VPLS that cannot load balance across 871

peering PEs. 872

873

It must be possible to connect a CE to two or more PEs for purposes of multi-homing and load 874

balancing as specified in Section 8 and 14/RFC 7432 [39]. 875

11.5.1 All-Active Redundancy Mode 876

All-active redundancy mode allows the CE device to connect via a “single” Ethernet bundle to 877

multiple PEs using LAG. All the PEs must be allowed to forward traffic to/from that Ethernet 878

Segment. 879

880

[R-54] PE router MUST support “All-Active redundancy mode” as specified in Section 881

14/RFC 7432 [39]. 882

883

11.5.2 Single-Active Redundancy Mode 884



In this mode, when a CE is connected to two or more PEs over an Ethernet segment, only a single 885

PE must be allowed to forward traffic to/from that Ethernet Segment. In this mode the CE device 886

connect via “separate” Ethernet bundles to multiple PEs. 887

888

[R-55] PE router MUST support “Single-Active redundancy mode” as specified in Section 889

14/RFC 7432 [39]. 890

Fast Convergence 891

Section 17/RFC 7432 provides failure recovery from different types of network failures. VPLS 892

relies on the underlying MPLS capabilities such as Fast Reroute. Lack of all-active multi-homing 893

in VPLS makes it difficult to achieve fast restoration in case of an edge node or edge link failure. 894

895

[R-56] The PEs MUST support convergence as specified in Section 17/RFC 7432 [39]. 896

897

898



12 EVPN enabled multipoint to multipoint Ethernet VPN services (E-LAN) 899

The EVPN technology enables the creation of multipoint-to-multipoint Ethernet VPN services 900

over an MPLS network. EVPN can be used to create the EP-LAN and EVP-LAN services of the 901

E-LAN service type defined by MEF 6.2. A high-level reference architecture of how these 902

services are architected using EVPN along with the list of the supported service attributes is 903

described in Section 12.1 and 12.2. In addition to the Carrier Ethernet defined service 904

characteristics, EVPN significantly enhances important service characteristics such as reliability 905

and scalability. The EVPN requirements for multipoint-to-multipoint Ethernet VPN services are 906

listed in Section 12.3. 907

Ethernet Private LAN (EP-LAN) 908

The Ethernet Private LAN (EP-LAN) service uses a multipoint-to-multipoint EVC. In a 909

multipoint EVC, two or more UNIs must be associated with one another. The EP-LAN service is 910

defined to provide CE-VLAN tag preservation and tunneling of key Layer 2 control protocols. A 911

key advantage of this service is that VLANs can be configured across the sites without any need to 912

coordinate with the service provider. 913

914

EP-LAN provides connectivity to customers with multiple sites, such that all sites appear to be on 915

the same local area network. Each interface is configured for “All to One Bundling”. EP-LAN 916

supports CE-VLAN CoS preservation. Service multiplexing is disabled on the UNI. 917

918

919

920 Figure 4 Ethernet Private LAN (EP-LAN) Service 921

922

923



Ethernet Virtual Private LAN (EVP-LAN) 924

The Ethernet Virtual Private LAN (EVP-LAN) service allows service multiplexing at the UNI. It 925

allows users of an E-LAN service type to interconnect their UNIs and at the same time access 926

other services (e.g. E-Line). Figure 5 shows an example of multiple services access from a single 927

UNI. In this example, the user has an EVP-LAN service for multipoint data connectivity and an 928

EVPL service (P2P EVC) for accessing a value-add service from one of the UNIs. 929

930

Bundling can be used on the UNI in the EVP-LAN service and supports CE-VLAN tag 931

preservation. All to One Bundling is disabled. 932

933

934 Figure 5 Ethernet Virtual Private LAN (EVP-LAN) Service 935

936

EVPN for establishing EP-LAN and EVP-LAN 937

Section 5 provides an overview of PPVPN in MPLS networks. It also outlines the comparison of 938

Layer 2 Ethernet VPNs in MPLS networks using VPLS and EVPNs. 939

940

EVPN provides support for the E-LAN service type in MPLS networks as described in Section 11. 941

RFC 7432 describes procedures for BGP MPLS-based Ethernet VPNS. EVPN requires extensions 942

to existing IP/MPLS protocols. EVPN supports both provisioning and signaling for Ethernet 943

VPNs and incorporate flexibility for service delivery over Layer 3 networks. 944

945

The PE supports BGP MPLS-based Ethernet VPN signaling and provisioning as specified in [R-946

53] of Section 11.4. 947

948



12.3.1 Service Interfaces 949

EVPN supports several service connectivity options for delivering MEF services. They are 950

provided in Section 11.2. MEF service requirements for EP-LAN and EVP-LAN are different. 951

For EP-LAN, each interface is configured for “All to One Bundling”. For EVP-LAN “All to One 952

Bundling” is disabled. VLAN-Aware Bundle service interface is not supported in VPLS-based 953

implementation (TR-224). When interworking with TR-224, it is recommended not to use VLAN-954

Aware Bundle service interface. This service interface provides a more flexible service offering 955

and is commonly used for data center interconnect. 956

Service Interfaces for EP-LAN 957

[R-57] The PE routers MUST support Port-based Service Interface as defined in Section 958

6.2.1/RFC 7432 [39]. 959

960

[R-58] The PE routers SHOULD support Port-Based VLAN-Aware Service Interface as 961

defined in Section 6.3.1/RFC 7432 [39]. 962

12.3.1.1.1 Data Center Considerations 963

If the PE router is designed for use in a data center interconnect environment, the following 964

requirement is applicable: 965

966

[R-59] The PE routers MUST support Port-Based VLAN-Aware Service Interface as 967

defined in Section 6.3.1/RFC 7432 [39]. 968

Service Interfaces for EVP-LAN 969

[R-60] The PE routers MUST Support VLAN-based Service Interface as defined in Section 970

6.1/RFC 7432 [39]. 971

972

[R-61] The PE routers MUST support VLAN Bundle Service Interface as defined in 973

Section 6.2/RFC 7432 [39] 974

975

[R-62] The PE routers SHOULD support VLAN-Aware Bundle Service Interface as 976

defined in Section 6.3/RFC 7432 [39]. 977

12.3.1.2.1 Data Center Considerations 978

If the PE router is designed for use in a data center interconnect environment, the following 979

requirement is applicable: 980

981

[R-63] The PE routers MUST support VLAN-Aware Bundle Service Interface as defined 982

in Section 6.3/RFC 7432 [39]. 983

984

985



12.3.2 Data plane 986

The requirements for data plane per Section 11.3 are applicable. 987

Local learning 988

[R-64] The PE MUST be able to do data-plane learning of MAC addresses using IEEE 989

Ethernet learning procedures for packets received from the CEs connected to it as specified 990

in Section 9.1/RFC 7432 [39]. 991

Remote learning 992

[R-65] The PE MUST be able to do control-plane learning of MAC addresses using MP-993

BGP’s MAC Advertisement route for CEs that are connected to remote PEs as specified in 994

Section 9.2/RFC 7432 [39]. 995

12.3.3 Tunnel signaling 996

The PEs are connected by MPLS Label Switch Paths (LSPs) acting as PSN tunnels. Traffic 997

Engineered PSN tunnels must be used when specific path (e.g. for protection purpose), QoS, or 998

bandwidth constraints are required. 999

1000

[R-66] PE and P routers MUST support dynamic signaling to setup both TE LSPs and 1001

routed LSPs. See Section 7.1 for details. 1002

12.3.4 Routing 1003

The requirements for routing per Section 7.2 are applicable. 1004

12.3.5 Multi-Homing and Load balancing 1005

The requirements for multi-homing and load balancing per Section 11.5 are applicable. 1006

Load balancing at intermediate nodes 1007

When load balancing, packets that belong to a given ‘flow’ must be mapped to the same port. 1008

Intermediate P nodes have no information about the type of the payload inside the LSP. 1009

Intermediate LSR should make a forwarding choice based on the MPLS label stack. In order to 1010

avoid any mis-ordering of frames, the requirements specified in Section 11.3.4 apply. 1011

1012

The PE that has knowledge of the Ethernet service (e.g. Bundling or multiclass service) can take 1013

further action. IETF RFC 6790 [36] provide methods of assigning labels to flows, or flow groups, 1014

such that Label Switching Routers can achieve better load balancing. 1015

1016

[R-67] The PE SHOULD support Entropy Labels as per RFC 6790 [36]. 1017

1018



1019

1020

1021

12.3.6 OAM 1022

Ethernet Link OAM 1023

The Ethernet link OAM is supported as per Section 8.1.1. 1024

Label Switched Paths (LSP) OAM 1025

LSP OAM is supported as per Section 8.3.1. 1026

MEF Service OAM 1027

MEF service is supported as per Section 8.1.2. 1028


Failure recovery from different types of network failure is supported as per Section 8.3.2. 1030

12.3.8 PSN Resiliency 1031

PSN resiliency is supported as per Section 10. 1032

1033


Fast convergence is supported as per Section 11.6. 1035

12.3.9 Multicast and Broadcast 1036

[R-68] PE routers SHOULD support multicast and broadcast traffic as per Section 16/RFC 1037

7432 [39]. 1038

12.3.10 QoS 1039

In general, an E-LAN service type can provide a best effort service with no performance 1040

assurance. In certain cases, an E-LAN service type can be defined with performance objectives 1041

(see Section 9.2/MEF 6.2 [50]. 1042

1043

[R-69] PE routers SHOULD support the QoS mapping as per Section 9. 1044

12.3.11 Security 1045



[R-70] PE routers MUST support security as per Section 19/RFC 7432 [39]. 1046

Support of service attributes for EP-LAN and EVP-LAN 1047

Section 9.2/MEF 6.2 [50] specifies the E-LAN service type that is the basis for LAN services. 1048

Section 10.3 and 10.4/MEF 6.2 [50] provides service attributes and parameters for EP-LAN and 1049

EVP-LAN services respectively. TR-224 refers to MEF 6.1 and MEF 10.2. TR-350 uses the 1050

backward compatible subset of the revised specifications MEF 6.2 [50] (see Appendix B) and 1051

MEF 10.3 [49] to achieve the equivalent function. 1052

1053

Some of the service attributes and parameters are provided by Ethernet physical interface and 1054

service provisioning (e.g., Physical medium, Speed, Mode, MAC layer, EVC type, maximum 1055

number of EVCs, etc.). This section only describes those service attributes and parameters that are 1056

relevant to transporting the EVPN traffic over PSN. 1057

12.4.1 Bandwidth Profile 1058

A bandwidth profile defines how rate enforcement of Ethernet frames is applied at an UNI. 1059

Bandwidth profiles enable offering service bandwidth below the UNI access speed (aka Speed) 1060

and limit the amount of traffic entering the network per the terms of the SLA. 1061

1062

For LAN services, bandwidth profiles can be optionally specified per-UNI (ingress and egress), 1063

per-EVC (ingress and egress), and/or per CoS (ingress and egress). An E-LAN service can be 1064

provided as a best effort service without any bandwidth guarantee. 1065

1066

[R-71] A PE SHOULD support the bandwidth profile algorithm as per the portion of 1067

Section 12/MEF 10.3 [49] that is backward compatible with MEF 10.2 [42]. 1068

1069

In order to support bandwidth profile, technique such as admission control and Diffserv-TE as 1070

specified in Section 9 are used. 1071

12.4.2 Bundling 1072

Section 9.12/MEF 10.3 [49] specifies the bundling service attribute. Bundling implies “A UNI 1073

attribute in which more than one CE-VLAN ID can be associated with an EVC”. All to one 1074

bundling enabled is a special case of bundling. It implies “A UNI attribute in which all CE-VLAN 1075

IDs are associated with a single EVC”. Table 12/MEF 10.3 [49] provides valid combinations for 1076

“All to one bundling” and “Service multiplexing” attributes. 1077

1078

EP-LAN must have “All to one bundling” attribute enabled. For EVP-LAN the bundling attribute 1079

can be enabled or disabled. However, for EVP-LAN “All to one bundling” must be disabled. 1080

1081

12.4.3 CE-VLAN ID preservation for EVC 1082



CE-VLAN ID preservation service attribute defines whether the CE-VLAN ID is preserved 1083

(unmodified) across the EVC. 1084

1085

For EP-LAN, CE-VLAN ID preservation must be enabled and CE-VLAN ID is preserved for EVC 1086

over the PSN. 1087

1088

For EVP-LAN, if CE-VLAN ID preservation is enabled, CE-VLAN ID is preserved for EVC over 1089

the PSN. 1090

1091

Note: If CE-VLAN ID preservation is enabled, No VID translation is supported for the EVC. 1092

EVP-LAN can support VID translation when using EVPN service type “VLAN-Based Service 1093

type” and “VLAN-Aware Bundle service interface”. 1094

12.4.4 CE-VLAN CoS preservation for EVC 1095

CE-VLAN CoS preservation service attribute defines whether the CE-VLAN CoS bits are 1096

preserved (unmodified) across the EVC. 1097

1098

For EP-LAN, CE-VLAN CoS preservation must be enabled (see Table 15/MEF 6.2 [50]) and CE-1099

VLAN CoS is preserved for EVC over PSN. 1100

1101

For EVP-LAN, CE-VLAN CoS preservation can be either enabled or disabled (see Table 18/MEF 1102

6.2). In an EVC with CE-VLAN CoS preservation is enabled, the EVPN preserves the CoS bits 1103

over PSN. 1104

12.4.5 EVC Maximum Service Frame Size 1105

The mapping from “EVC Maximum Service Frame Size” to “EVC MTU” is provided in Table 40 1106

Appendix B of MEF 6.2 [50]. 1107

1108

The EVC Maximum Service Frame Size size is configurable with a default value of 1600 byte. 1109

1110

When Ethernet frames are transported in MPLS networks, the MPLS packet includes the labels, 1111

and the EVC frame as payload. The path MTU is the largest packet size that can traverse this path 1112

without fragmentation. The ingress PE can use Path MTU Discovery to find the actual path MTU. 1113

1114

[R-72] PE SHOULD support configurable EVC Maximum Service Frame Size of at least 1115

1600 bytes (see Table 6/MEF 6.2). 1116

1117

1118

1119

1120

12.4.6 Frame delivery 1121



The frame delivery policy rules enable the service provider to specify how different frame types 1122

are handled by a PE. They enable setting specific rules for forwarding, discarding or conditionally 1123

forwarding specific frame types. The frame types used by the rules are: 1124

1125

• Unicast 1126

• Multicast 1127

• Broadcast 1128

1129

[R-73] PE MUST support setting policy function of frame delivery rules for 1130

forwarding, discarding or conditionally forwarding unicast, multicast and 1131

broadcast frames per EP-LAN and EVP-LAN services. 1132

12.4.7 Layer 2 control protocols 1133

The Layer 2 control protocol processing is independent of the EVC at the UNI. L2CP handling 1134

rules are set according to the definition of Section 8/MEF 6.1.1 [48] and differ per-service type. 1135

The PE policy function supports setting of rules for handling L2CP per service type. 1136

1137

EVC L2CP handling per service type can be set to: 1138

• Discard – Drop the frame. 1139

• Peer can be applicable: For example L2CP/LAMP, Link OAM, Port Authentication, and E-1140

LMI. 1141

• Tunnel – Pass to the egress UNI. 1142

1143

[R-74] PE MUST support policy function setting of rules for handing L2CP per service 1144

type as specified in Section 8/MEF 6.1.1 [48]. 1145

1146

Note: This specification only supports MEF 6.1.1 for L2CP processing 1147

requirements. Support of multiple-CEN L2CP MEF 45 [51] is outside the scope of 1148

this document. 1149

12.4.8 EVC performance 1150

The performance parameters indicate the quality of service for that service instance. They consist 1151

of the following: 1152

• Availability 1153

• Frame Delay 1154

• Frame delay variation 1155

• Frame loss ratio 1156

1157

The requirements for support of CoS and mapping are specified in QoS Section 9. 1158

1159

[R-75] The PE MUST support MEF SOAM performance monitoring as per MEF 35 [47]. 1160

1161

For transport of SOAM see Section 8.2. 1162



1163

1164

1165



13 EVPN enabled point to point Ethernet VPN services (E-Line) 1166

The Ethernet Line service is defined in MEF 6.2 [50] and is based on a point-to-point Ethernet 1167

Virtual Connection (EVC). Virtual Private Wire Service (VPWS) is a Layer 2 VPN service used 1168

to emulate the E-Line service type in an MPLS network. draft-ietf-bess-evpn-vpws Error! R1169

eference source not found. describes how EVPN can be used to support VPWS in IP/MPLS 1170

networks. The use of EVPN mechanisms for VPWS brings the benefits of EVPN to point-to-point 1171

services. EVPN can be used to create the Ethernet Private Line (EPL) and Ethernet Virtual Private 1172

Line (EVPL) services of the E-Line service type defined by MEF 6.2 [50]. 1173

1174

A high-level reference architecture of how these services are architected using EVPN along with 1175

the list of the supported service attributes is described in Section 13.1 and 13.2. In addition to the 1176

Carrier Ethernet-defined service characteristics, EVPN significantly enhances important service 1177

characteristics such as reliability and scalability. The EVPN-VPWS requirements for point-to-1178

point Ethernet VPN services are listed in Section 13.3. 1179

Ethernet Private Line (EPL) 1180

Ethernet Private Line (EPL), uses a point-to-point EVC between two UNIs to provide a high 1181

degree of transparency for service frames between UNIs it interconnects. The service frames, 1182

headers, and most Layer 2 protocols are identical at both the source and destination UNI. It does 1183

not allow for service multiplexing; that is, a dedicated UNI (physical interface) is used for the 1184

EPL. The figure below shows EPL service. 1185

1186

A key advantage of this service is that VLANs can be configured across the sites without any need 1187

to coordinate with the service provider. Each interface is configured for “All to One Bundling”. 1188

EPL supports CE-VLAN CoS preservation. For cases where an ingress bandwidth profile is 1189

applied, the CE is expected to shape traffic. 1190

1191

1192



1193 1194

1195

1196

1197

Ethernet Private Line (EPL): 1198

• It replaces a TDM private line 1199

• Dedicated UNIs for Point-to-Point connections 1200

• Single Ethernet Virtual Connection (EVC) per UNI 1201

• The most popular Ethernet service type due to its simplicity 1202

Ethernet Virtual Private Line (EVPL) 1203

Ethernet Virtual Private Line (EVPL) uses a point-to-point EVC between two UNIs, but does not 1204

provide full transparency as with the EPL service. The EVPL service also allows for service 1205

multiplexing, which means that more than one EVC can be supported at the UNI. Because service 1206

multiplexing is permitted, some service frames may be sent to one EVC, while other service 1207

frames may be sent to other EVCs. The service definition for EVPL is specified in Section 1208

10.1/MEF 6.2 [50]. 1209

1210

EVPL is commonly used for connecting subscriber hub and branch locations. It allows users of an 1211

E-Line service type to interconnect their UNIs and at the same time access other services (e.g. E-1212

LAN). Figure 7 shows an example of multiple services access from a single UNI. In this example, 1213

the user has an EVP-LAN service for multipoint data connectivity and an EVPL service (P2P 1214

EVC) for accessing a value-add service from one of the UNIs. Bundling can be used on the UNI 1215

in the EVPL service and supports CE-VLAN tag preservation. All to One Bundling is disabled. 1216

Figure 6 Ethernet Private Line (EPL) Service



1217 1218

EVPN for establishing EPL and EVPL 1219

VPWS support in EVPN draft-ietf-bess-evpn-vpws Error! Reference source not found. describes h1220

ow EVPN can be used to support VPWS in IP/MPLS networks. EVPN enables the following 1221

service capabilities: single-active as well as all-active multi-homing; flow-based load balancing; 1222

and policy. It eliminates the need for PWs for point-to-point Ethernet services. EVPN has the 1223

ability to forward customer traffic at the PE without any MAC lookup because the MPLS label 1224

associated with the EVI is used. EVPL can be considered as a VPWS with only two-attachment 1225

circuits (AC) or MEF-UNIs. For additional details see draft-ietf-bess-evpn-vpws Error! R1226

eference source not found.. 1227

1228

RFC 7432 [39] describes procedures for BGP MPLS-based Ethernet VPNs. EVPN requires 1229

extensions to existing IP/MPLS protocols. EVPN supports both provisioning and signaling for 1230

Ethernet VPNs and incorporates flexibility for service delivery over Layer 3 networks. 1231

1232

1233

The PE supports BGP MPLS-based Ethernet VPN signaling and provisioning as specified in 1234

requirement [R-53] of Section 11.4. 1235


EVPN-VPWS supports several service connectivity options for delivering MEF services. They are 1237

provided in Section 2/draft-ietf-bess-evpn-vpws Error! Reference source not found.. This s1238

ervice does not use “VLAN-Aware Bundle Service interface”. . 1239

1240

Figure 7 Ethernet Virtual Private Line (EVPL) Service



MEF service requirements for EPL and EVPL are different. For EPL, each interface is configured 1241

for “All to One Bundling”. For EVPL “All to One Bundling” is disabled. 1242

Service Interfaces for EPL 1243


6.2.1/RFC 7432 [39]. 1245

1246

Service Interfaces for EVPL 1247


2.1/draft-ietf-bess-evpn-vpws Error! Reference source not found.. 1249

1250


Section 2.2/draft-ietf-bess-evpn-vpws Error! Reference source not found.. 1252

1253

13.3.2 Operation 1254

PE routers must support point to point deployments as defined in Section 4/draft-ietf-bess-evpn-1255

vpws Error! Reference source not found.. 1256

13.3.3 Data Plane 1257

The requirements for data plane per Section 11.3.1 and 11.3.2 are applicable. 1258

Local learning 1259

The requirements for local learning per Section 12.3.2.1 are applicable. 1260

Remote learning 1261

The requirements for remote learning per Section 12.3.2.2 are applicable. 1262

13.3.4 BGP extensions 1263

EVPN-VPWS uses the Ethernet A-D per-EVI route to signal VPWS services. An EVPN instance 1264

MUST NOT be configured with both VPWS service instance and EVPN multipoint services. 1265

draft-ietf-bess-evpn-vpws Error! Reference source not found. Section 3.1 adds a EVPN Layer 2 a1266

ttributes extended community. 1267

1268

[R-79] The PE routers MUST support EVPN Layer 2 attributes extended community as 1269

defined in Section 3.1/draft-ietf-bess-evpn-vpws Error! Reference source not found.. 1270




The requirements for tunnel signaling per Section 12.3.3 are applicable. 1272

13.3.6 Routing 1273



The requirements for multi-homing and load balancing per Section 11.5 are applicable. 1276

Load balancing at intermediate nodes 1277

The requirements for load balancing at intermediate nodes per Section 12.3.5.1 are 1278

applicable. 1279

13.3.8 OAM 1280

Ethernet Link OAM 1281

The Ethernet link OAM is supported as per Section 8.1.1. 1282

Label Switched Paths (LSP) OAM 1283

LSP OAM is supported as per Section 8.3.1. 1284

MEF Service OAM 1285

MEF service is supported as per Section 8.2. 1286







13.3.11 QoS 1293



E-Line service type can be defined with performance objectives (see Section 9.1/MEF 6.2 [50]). 1294

PE routers MUST support the QoS mapping as per Section 9. 1295

13.3.12 Security 1296


Support of service attributes for EPL and EVPL 1298

Section 9.1/MEF 6.2 [50] specifies the Ethernet Line (E-Line) Service Type that is the basis for a 1299

broad range of Point-to-Point services. Section 10.1 and 10.2/MEF 6.2 [50] provides service 1300

definitions for the Ethernet Private Line (EPL) Service and the Ethernet Virtual Private Line 1301

(EVPL) Service that are based on the E-Line Service Type by defining the required Service 1302

Attributes and related parameter values. The service attributes are tabulated in Section 8/MEF 6.2 1303

[50]. 1304

1305

TR-224 refers to MEF 6.1 [41] and MEF 10.2 [42]. TR-350 uses the backward compatible subset 1306

of the revised specifications MEF 6.2 [50] and MEF 10.3 [49] to achieve the equivalent function. 1307

This addresses interworking with TR-224. 1308

1309

This section only describes those Service Attributes and parameters that are relevant to 1310

transporting the service over the PSN. 1311


A bandwidth profile characterizes the lengths and arrival times of Service frames at a reference 1313

point. Bandwidth profiles enable offering service bandwidth below the UNI access speed (aka 1314

Speed) and limit the amount of traffic entering the network per the terms of the SLA. 1315

1316

For the EPL and EVPL service, bandwidth profiles can be optionally specified per-UNI (ingress 1317

and egress), per-EVC (ingress and egress), and/or per CoS (ingress and egress) as specified in 1318

Section 10.1 and 10.2/MEF 6.2 [50]. The EPL and EVPL service can be provided as a best effort 1319

service without any bandwidth guarantee. 1320

1321

Note: Bandwidth profiles can be optionally provisioned per UNI (ingress and egress). They are not 1322

carried by EVPN protocols. 1323

1324



1327






Bundling is defined in Section 2/MEF 10.3 [49] as “A UNI Service attribute in which more than 1331

one CE-VLAN ID can be associated with an EVC” and is described in Section 9.12/MEF 10.3 1332

[49]. All to one bundling defined as “A UNI attribute in which all CE-VLAN IDs are associated 1333

with a single EVC” is a special case of Bundling Enabled and is described in Section 9.13/MEF 1334

10.3 [49]. Table 12/MEF 10.3 [49] provides valid combinations for “Service multiplexing”, 1335

“Bundling” and “All to one bundling” attributes. 1336

1337

EPL must have the “Bundling” attribute as disabled and “All to one bundling” attribute as enabled. 1338

For EVPL the “Bundling” attribute can be enabled or disabled, but “All to one bundling” must be 1339

disabled. 1340


For EPL, CE-VLAN ID preservation must be enabled and CE-VLAN ID is preserved for EVC 1342

over the PSN. 1343

1344

For EVPL, if CE-VLAN ID preservation is enabled, CE-VLAN ID is preserved for EVC over the 1345

PSN. 1346

1347


EVPL can support VID translation when using EVPN service type “VLAN-Based Service type”. 1349




1353

For EPL, CE-VLAN CoS preservation may be enabled or disabled (see Table 12/MEF 6.2 [50]). 1354

For EVPL CE-VLAN CoS is supported as per sec 10.3/MEF 6.2 [50] and may be enabled or 1355

disabled. In an EVC with CE-VLAN CoS preservation is enabled, the EVPN preserves the CoS 1356

bits over PSN. 1357


The mapping from “EVC Maximum Service Frame Size” to “EVC MTU” is provided in Table 40 1359

Appendix B of MEF 6.2 [50]. 1360

1361

The EVC Maximum Service Frame Size is configurable with a default value of 1600 bytes. 1362

1363

When Ethernet frames are transported in MPLS networks, the MPLS packet includes the labels, 1364

and the EVC frame as payload. The path MTU is the largest packet size that can traverse this path 1365

without fragmentation. The ingress PE can use Path MTU Discovery to find the actual path MTU. 1366

1367

[R-82] PE SHOULD support configurable EVC Maximum Service Frame Size of at least 1368

1600 bytes (see Table 6/MEF 6.2 [50]). 1369







1374

• Unicast 1375

• Multicast 1376

• Broadcast 1377

1378

[R-83] PE MUST support setting policy function of frame delivery rules for forwarding, 1379

discarding or conditionally forwarding unicast, multicast and broadcast frames per EPL and 1380

EVPL services. 1381


The Layer 2 control protocol processing is independent of the EVC at the UNI. L2CP handling 1383

rules are set according to the definition of Section 8/MEF 6.1.1 [48] and differ per-service type. 1384

The PE policy function supports setting of rules for handling L2CP per service type. 1385

1386

EVC L2CP handling per service type can be set to: 1387

• Discard – Drop the frame. 1388

• Peer can be applicable: For example L2CP/LAMP, Link OAM, Port Authentication, and E-1389

LMI. 1390

• Tunnel – Pass to the egress UNI. 1391

1392

[R-84] PE MUST support policy function setting of rules for handing L2CP per service 1393

type as specified in Section 8/MEF 6.1.1 [48]. 1394

1395

Note: This specification only supports MEF 6.1.1 for L2CP processing equirements. 1396

Support of multiple-CEN L2CP MEF 45 [51] is outside the scope of this document. 1397


The performance parameters indicate the quality of service for that service instance. They consist 1399

of the following: 1400

• Availability 1401

• Frame Delay 1402

• Frame delay variation 1403

• Frame loss ratio 1404

1405

The requirements for support of CoS and mapping are specified in QoS Section 9. 1406

1407

[R-85] The PE MUST support MEF SOAM performance monitoring as per MEF 35 [47]. 1408

1409



For transport of SOAM see Section 8.2. 1410

13.4.9 Multiple Class of Service 1411

MEF 6.1 [41] introduced services that were allowed multiple Classes of Service. The different 1412

ways that EVCs can be created to support such a service is defined in Section 11.4.9/MEF 6.1 [41]. 1413

1414

[R-86] The PE MUST support a single class of service for an EVC by using a single value 1415

for the TC bits in the MPLS label stack. 1416

1417

[R-87] The PE MUST support a multiple class of service for an EVC by using multiple 1418

values for the TC bits in the MPLS label stack. 1419

1420

1421



14 EVPN enabled Rooted-multipoint Ethernet VPN services (E-Tree) 1422

MEF Ethernet Tree (E-Tree) service type is based upon a Rooted-multipoint Ethernet Virtual 1423

connection. The EVPN technology enables the creation of E-Tree services over an MPLS network. 1424

EVPN can be used to create the EP-Tree and EVP-Tree services of the E-Tree service type defined 1425

by MEF 6.2 [50]. In an E-Tree service, endpoints are labeled as either Root or Leaf sites. Root 1426

sites can communicate with all other sites. Leaf sites can communicate with Root sites but not with 1427

other Leaf sites. 1428

1429

This service could be useful for internet access or video over IP application, such as 1430

multicast/broadcast packet video. 1431

1432

High-level services are described in Section 14.1and 14.2. In addition to the Carrier Ethernet 1433

defined service characteristics, EVPN significantly enhances important service characteristics such 1434

as reliability and scalability. The EVPN requirements for E-Tree Ethernet VPN services are listed 1435

in Section 14.3. 1436

Ethernet Private Tree (EP-Tree) 1437

The Ethernet Private Tree (EP-Tree) service uses a Rooted-multipoint EVC. In a multipoint EVC, 1438

two or more UNIs must be associated with one another. The EP-Tree service is defined to provide 1439

CE-VLAN tag preservation and tunneling of key Layer 2 control protocols. A key advantage of 1440

this service is that VLANs can be configured across the sites without any need to coordinate with 1441

the service provider. 1442

1443

Each interface is configured for “All to One Bundling”. EP-LAN supports CE-VLAN CoS 1444

preservation. Service multiplexing is disabled on the UNI. 1445

1446



1447 1448

Figure 8 Ethernet Private Tree (EP-Tree) Service 1449

Ethernet Virtual Private Tree (EVP-Tree) 1450

The Ethernet Virtual Private Tree (EVP-Tree) service allows service multiplexing at the UNI. It 1451

allows users of an E-Tree service to interconnect their UNIs and at the same time access other 1452

services (e.g. E-Line). Figure 9 shows an example of multiple services access from a single UNI. 1453

In this example, the user has an EVP-Tree service for Rooted-multipoint data connectivity and an 1454

EVPL service (P2P EVC) for accessing a value-add service from one of the UNIs. 1455

1456

Bundling can be used on the UNI in the EVP-Tree service and supports CE-VLAN tag 1457

preservation. All to One Bundling is disabled. 1458

1459



1460 1461

Figure 9 Ethernet Virtual Private Tree (EVP-Tree) Service 1462

1463

EVPN for establishing EP-Tree and EVP-Tree 1464

L2VPN service provides multipoint to multipoint connectivity for Ethernet across an IP or MPLS 1465

Network. A generic E-LAN/E-Tree service is always bidirectional in the sense that ingress frames 1466

can originate at any endpoint in the service. 1467

1468

The only difference between E-LAN and E-Tree is: 1469

• E-LAN has Root endpoints only, which implies there is no communication restriction 1470

between endpoints. 1471

• E-Tree has both Root and Leaf endpoints, which implies there is a need to enforce 1472

communication restriction between Leaf endpoints. 1473

1474

RFC 7387[38] proposes the solution framework for supporting E-Tree service in MPLS networks. 1475

The document identifies additional components to emulate E-Tree service using Ethernet LAN 1476

service over MPLS network. 1477

1478

EVPN provides support for the E-LAN service type in MPLS networks as described in Section 11. 1479

RFC 7432 [39] describes procedures for BGP MPLS-based Ethernet VPNS. EVPN requires 1480

extensions to existing IP/MPLS protocols. EVPN supports both provisioning and signaling for 1481

Ethernet VPNs and incorporates flexibility for service delivery over Layer 3 networks. 1482

1483

The PE supports BGP MPLS-based Ethernet VPN signaling and provisioning as specified in [R-1484

53] of Section 11.4. 1485



draft-ietf-bess-evpn-etree [52] describes how EVPN can be used to support E-Tree in IP/MPLS 1486

networks. The RFC discusses how the functional requirements for E-Tree service can be 1487

implemented efficiently with EVPN. 1488

14.3.1 E-Tree support in EVPN 1489

E-Tree Scenarios and EVPN Support 1490

The support for E-Tree services in EVPN is divided into different scenarios, depending on the site 1491

association (Root/Leaf) per PE or Access Ethernet Segment. They are described in section 2/ 1492

draft-ietf-bess-evpn-etree [52]. 1493

1494

[R-88] The PE routers MUST Support Leaf or Root site(s) per PE as defined in Section 1495

2.1/ draft-ietf-bess-evpn-etree [52]. 1496

1497

[R-89] The PE routers MUST Support Leaf or Root site(s) per Attachment Circuit (AC) as 1498

defined in Section 2.2/ draft-ietf-bess-evpn-etree [52]. 1499

1500

E-Tree Extended Community 1501

A new BGP extended community is used for leaf indication. They are described in section 5/ draft-1502

ietf-bess-evpn-etree [52]. 1503

1504

[R-90] The PE routers MUST Support BGP extended community encoding as defined in 1505

Section 5/ draft-ietf-bess-evpn-etree [52]. 1506

E-Tree Operation for EVPN 1507

RFC 7432 [39] has inherent capability to support E-Tree service. It adds a new 1508

BGP extended community for leaf indication. The E-Tree operations for EVPN are 1509

described in section 3/ draft-ietf-bess-evpn-etree [52]. 1510

[R-91] The PE routers MUST Support E-Tree operation for EVPN as defined in Section 3/ 1511

draft-ietf-bess-evpn-etree [52]. 1512


EVPN supports several service connectivity options for delivering MEF services. They are 1514

provided in Section 11.2. MEF service requirements for EP-LAN and EVP-LAN are different. 1515

For EP-LAN, each interface is configured for “All to One Bundling”. For EVP-LAN “All to One 1516

Bundling” is disabled. 1517

Service Interfaces for EP-Tree 1518


6.2.1/RFC 7432 [39]. 1520



1521

Service Interfaces for EVP-Tree 1522


6.1/RFC 7432 [39]. 1524

1525


Section 6.2/RFC 7432 [39] 1527

14.3.3 Data plane 1528

The requirements for data plane per Section 12.3.2 are applicable. 1529


The requirements for tunnel signaling per Section 12.3.3 are applicable. 1531

14.3.5 Routing 1532



The requirements for multi-homing and load balancing per Section 12.3.5 are applicable. 1535

14.3.7 OAM 1536

The requirements for OAM per Section 12.3.6 are applicable. 1537





1542



14.3.10 Multicast and Broadcast 1545



[R-95] PE routers SHOULD support multicast and broadcast traffic as per Section 16/RFC 1546

7432 [39]. 1547

14.3.11 QoS 1548

In general, an E-Tree service type can provide a best effort service with no performance assurance. 1549

In certain cases, an E-Tree service type can be defined with performance objectives (see Section 1550

9.2/MEF 6.2 [50]. 1551

1552

[R-96] PE routers SHOULD support the QoS mapping as per Section 9. 1553

14.3.12 Security 1554


1556

Support of service attributes for EP-Tree and EVP-Tree 1557

Section 9.3/MEF 6.2 [50] specifies the E-Tree service type. Section 10.5 and 10.6/MEF 6.2 [50] 1558

provides service attributes and parameters for EP-Tree and EVP-Tree services respectively. TR-1559

224 refers to MEF 6.1 [41] and MEF 10.2. TR-350 uses the backward compatible subset of the 1560

revised specifications MEF 6.2 [50] (see Appendix B) and MEF 10.3 [49] to achieve the 1561

equivalent function. 1562

1563

Some of the service attributes and parameters are provided by Ethernet physical interface and 1564

service provisioning (e.g., Physical medium, Speed, Mode, MAC layer, EVC type, maximum 1565

number of EVCs, etc.). This section only describes those service attributes and parameters that are 1566

relevant to transporting the EVPN traffic over PSN. 1567


A bandwidth profile defines how rate enforcement of Ethernet frames is applied at an UNI. 1569

Bandwidth profiles enable offering service bandwidth below the UNI access speed (aka Speed) 1570

and limit the amount of traffic entering the network per the terms of the SLA. 1571

1572

For Tree services, bandwidth profiles can be optionally specified per-UNI (ingress and egress), 1573

per-EVC (ingress and egress), and/or per CoS (ingress and egress). An E-Tree service can be 1574

provided as a best effort service without any bandwidth guarantee. 1575

1576

Note: Bandwidth profiles can be optionally provisioned. They are not carried by EVPN protocols. 1577

1578

1579



1582






Section 9.12/MEF 10.3 [49] specifies the bundling service attribute. Bundling implies “A UNI 1586

attribute in which more than one CE-VLAN ID can be associated with an EVC”. All to one 1587

bundling enabled is a special case of bundling. It implies “A UNI attribute in which all CE-VLAN 1588

IDs are associated with a single EVC”. Table 12/MEF 10.3 [49] provides valid combinations for 1589

“All to one bundling” and “Service multiplexing” attributes. 1590

1591

EP-Tree must have “All to one bundling” attribute enabled. For EVP-Tree the bundling attribute 1592

can be enabled or disabled. However, for EVP-Tree “All to one bundling” must be disabled. 1593


CE-VLAN ID preservation service attribute defines whether the CE-VLAN ID is preserved 1595

(unmodified) across the EVC. 1596

1597

For EP-Tree, CE-VLAN ID preservation must be enabled and CE-VLAN ID is preserved for EVC 1598

over the PSN. 1599

1600

For EVP-Tree, if CE-VLAN ID preservation is enabled, CE-VLAN ID is preserved for EVC over 1601

the PSN. 1602

1603


EVP-Tree can support VID translation when using EVPN service type “VLAN-Based Service 1605

type”. 1606




1610

For EP-Tree, CE-VLAN CoS preservation must be enabled (see Table 21/MEF 6.2 [50]) and CE-1611

VLAN CoS is preserved for EVC over PSN. 1612

1613

For EVP-Tree, CE-VLAN CoS preservation can be either enabled or disabled (see Table 24/MEF 1614

6.2). In an EVC with CE-VLAN CoS preservation is enabled, the EVPN preserves the CoS bits 1615

over PSN. 1616


The requirements for EVC maximum service frame size per Section 12.4.5 are applicable. 1618







1623

• Unicast 1624

• Multicast 1625

• Broadcast 1626

1627

[R-99] PE MUST support setting policy function of frame delivery rules for 1628

forwarding, discarding or conditionally forwarding unicast, multicast and 1629

broadcast frames per EP-Tree and EVP-Tree services. 1630


The requirements for Layer 2 control protocols per Section 12.4.7 are applicable. 1632

1633


The requirements for EVC performance per Section 12.4.8 are applicable. 1635

1636

1637

1638

1639

1640

End of Broadband Forum Technical Report TR-350 1641

1642

1643

1644

1645