e tree over mpls ethernet academy v3

8/6/2019 E Tree Over MPLS Ethernet Academy v3

1/14

Ethernet Academy 2010. All Rights Reserved.

MEF E-Tree Service Over MPLSNeeds, Myths and Challenges

Written by Simon Delord, Raymond Key and Frederic Jounay

Abstract

Ethernet services have been increasingly deployed by carriers over the last few years. The most successful so far

are E-Line (point-to-point) and E-LAN (multipoint-to-multipoint) services. To achieve carrier grade objectives, suchdeployments have been done over MPLS backbones. Recently though, carriers have seen the need for deploying anew type of Ethernet services called E-Tree over their infrastructure. This type of services is expected tocomplement the range of Ethernet products offered by carriers today with new possibilities and new applications,specifically in the distribution of content (typically video), mobile backhaul and clock synchronisation to onlymention a few. However, with any new type of services, new challenges also appear in relation to operationaldeployment.

This article highlights the different use cases and potential benefits of deploying E-Tree services over an MPLSbackbone. It also presents some of the short term and long term challenges facing such deployments and some ofthe elements currently under development in the Internet Engineering Task Force (IETF) to address these specificchallenges.


2/14


Introduction

Ethernet has evolved from a technology developed for Local Area Network (LAN) environments to a technologyused in Carriers networks.

Carriers have over the last few years started offering a variety of Ethernet services with the two most popular beingthe E-Line (point-to-point services) and E-LAN (multipoint-to-multipoint services) defined by the Metro EthernetForum (MEF) [1]. Carriers in their vast majority have taken the approach to deploy or reuse their multiprotocol

label switching (MPLS) networks to offer such services. The building block for encapsulating Ethernet frames overan MPLS network is a specific entity called a pseudowire (PW). The Internet Engineering Task Force (IETF) haspublished several request for comments (RFCs) detailing how such Ethernet services can be delivered over MPLSnetworks[2][3][4].

Root Root

LeafLeaf

Leaf

Carriers

Network

E-Line E-LAN E-Tree

Carriers

Network

Carriers

Network

Leaf Leaf

CommunicationNot Allowed

Figure 1.MEF Ethernet Service Types: E-Line, E-LAN and E-Tree.

Recently, carriers have started to see the need to offer a new type of multipoint Ethernet services defined by MEF,called E-Tree[1]. At the difference of E-Line and E-LAN where there are no communication restrictions betweenendpoints, on E-Tree each endpoint is designated as either a root or a leaf. Root can communicate with all otherendpoints on the E-Tree, however leaf can only communicate with roots but not leafs. There may be single root or

multiple roots in one E-Tree service. Carriers are looking at leveraging their current MPLS infrastructure to deployE-Tree services.

This article discusses the relevant use cases for E-Tree services as well as the immediate challenges and potentialdeployment options.
http://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://tools.ietf.org/html/rfc4448http://tools.ietf.org/html/rfc4448http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4448http://metroethernetforum.org/PDF_Documents/MEF6-1.pdf


3/14


Use Cases

Because of their specific topology, E-Tree service constructs are very well suited for content delivery applications.Typically, one or several root endpoints will be responsible for delivering some sort of content to multiple leafendpoints. Some of the scenarios are detailed further in this section but, broadcast video and clock synchronisationare some of the applications that could make use of such a service construct. Because in those scenarios, the rootendpoints will distribute the same information to many leaf endpoints, there is a strong potential for bandwidth

optimisation throughout the carriers network. Bandwidth optimisation mechanisms allow for a carrier to reduce theamount of traffic that needs to go through its physical infrastructure and therefore reduce deployment costs.

Interestingly, other applications may not benefit greatly or at all from bandwidth optimisation but will require theleaf-to-leaf communication restriction of E-Tree constructs. For example, applications such as Internet access orhub & spoke virtual private networks (VPNs) may have no need for bandwidth optimisation but definitely havestringent security requirements in terms of which endpoints are not allowed to communicate directly. This securityaspect for E-Tree also leads to another very important business application for E-Tree services which is their specificuse for wholesale offerings.

Typically, instead of deploying their own infrastructure, some carriers (or some application/content service providerswith no network infrastructure at all) that need to extend the reach of their services may rely on another carriers

infrastructure covering a specific area. This means that carriers only need to interconnect with other carriers atsome specific key locations called points of interconnect (POI) and rely on someone else infrastructure to delivertheir services to their customers. The carrier that owns the infrastructure (or called the infrastructure carrier) isthereforewholesalingnetwork services to another carrier. This is particularly relevant for the access and backhaulpart of the network.

Root Root

Leaf

Wholesale Customers

Point of Interconnect

Carriers

NetworkE-Tree

LeafLeaf

Wholesale Customers

Customer

Wholesale Providers

Network Infrastructure

Figure 2.E-Tree for Wholesale Access

Please also note that some applications may benefit from both the bandwidth optimisation and security aspects ofE-Tree service constructs. This would for example be the case for a hub & spoke VPN for franchise business whichrequires separation between franchisees and has broadcast video as one of the major applications on the VPN.


4/14


5/14


Clock Synchronization

This use case is about clock synchronisation using IEEE 1588 Precision Time Protocol (PTPv2). In the E-Treeconstruct, the PTP server is the root while each PTP client is a leaf. There may be multicast traffic from PTP serverto PTP clients and unicast traffic between PTP server and PTP client, but no traffic between PTP clients. Forredundancy, it is possible to have more than one root endpoints to support multiple PTP servers.

Root Root

Leaf

IEEE 1588 PTP Server

Carriers

NetworkE-Tree

LeafLeaf

IEEE 1588 PTP Client

Figure 5.E-Tree for Clock Synchronisation

This type of E-Tree service construct is bidirectional with both root to leaf and leaf to root communication. Thetraffic from root could be towards a single leaf or towards all leafs.

Mobile Backhaul

In mobile backhaul, there are two main elements, the radio access network base stations (RAN BS) and the RANnetwork controller (RAN NC). The RAN BS sites only need to exchange data with RAN NC sites. Latest models ofRAN NCs and RAN BSs support native Ethernet interfaces, therefore an E-Tree service construct where the RAN NCis a root and the RAN BSs are leafs could be used here.

Root Root

Leaf

RAN Network Controller

Carriers

Network

E-Tree

LeafLeaf

RAN Base Station

Figure 6.E-Tree for Mobile Backhaul

This type of E-Tree service construct is bidirectional with both root to leaf and leaf to root communication.Furthermore, there is also a mix of Ethernet traffic that will transit through this service construct. The traffic fromroot could be towards a single leaf or towards all leafs (clock synchronisation using IEEE1588 PTPv2 for example).


6/14


Internet Access

The most popular deployment of Internet access relies on E-Line based topology where a gateway router has onepoint-to-point logical interface towards each router deployed at the customer premises. The reason behind suchdesign is the required security separation between customers. This means that the gateway router has to maintaina large number of logical interfaces (one for each remote endpoint).

One alternative here would be to use an E-Tree service construct with the gateway router as a root and all therouters located on the customer premises as leafs. The two key points of E-Tree here are to provideprovisioning/maintenance simplification compared to the existing E-Line case while still maintaining the securityseparation between customers. Another advantage is the possibility to offer redundancy by adding a second (ormore) gateway router as another root endpoint without having to duplicate all of the provisioning as in the E-Linecase.

Root Root

Leaf

ISP Gateway Router

Carriers

NetworkE-Tree

LeafLeaf

Subscriber Router

Figure 7.E-Tree for Internet Access

This type of E-Tree service construct is bidirectional with both root to leaf and leaf to root communication. Herethere is no root to all leafs traffic, all traffic is always point to point between the root and a specific leaf.

The four previous use cases are some examples of how an E-Tree service could be used. As mentioned at thebeginning of this section there are also other applications that would benefit from the E-Tree services (such as hub& spoke VPNs, wholesaling, etc).

The important point to notice here, is that even though the Ethernet service constructs are the same (e.g. there isone or more roots, one or more leafs and no leaf-to-leaf communication) the key requirements that a particular E-Tree service must fulfil will change based on its application. In some cases efficient broadcast delivery is critical butsecurity is not really a concern (e.g. broadcast video), in some other cases efficient broadcast delivery is not reallyneeded as opposed to making sure that leafs do not talk to each other (e.g. Internet access).

The question for carriers is therefore whether there is a singlefit-all type ofE-Tree or a few variants are required.In order to address this question we must look at some of the myths around E-Tree services.


7/14


Some Myths

There are several myths generally associated with E-Tree constructs. Four of them are discussed here. The firstthree are around the generic E-Tree service definition; the fourth one is about the core topic of this article, theirdeployment over MPLS networks.

First Myth: Delivery Method Is The Same As Traditional Ethernet

The first myth usually associated to E-Tree is that a service frame in an E-Tree construct must follow the samedelivery rule as traditional Ethernet bridged/switched networks with the exception of the leaf-to-leaf communicationrestriction.

The traditional Ethernet delivery mechanism is MAC based forwarding. In simple words, that is dynamic learning ofMAC address at service endpoint based on source MAC address of ingress frame and frame delivery based ondestination MAC address in the frame. For known unicast address, deliver to the service endpoint associated withthat MAC address, otherwise (i.e. unknown unicast, broadcast or multicast) deliver to all other endpoints.

Lets look at what is stated in the MEF service definition [1]. For the Service Frame Delivery attributes, therequirement is specified asDeliver Unconditionally or Deliver Conditionally. If Delivered Conditionally, MUSTspecifythe delivery criteria. This allows a carrier to define the service frame delivery attribute for a particular E-Treeservice according to the specific application requirements (e.g. broadcast video, or Internet access, or hub & spoke

VPN, etc). Typically, such service frame delivery attribute will be MAC based forwarding same as traditionalEthernet delivery mechanism.

As presented in the previous section, different use cases may impose different requirements. MAC basedforwarding may be required in some cases but not always. A typical example is E-Tree construct for broadcastvideo, which is unidirectional root to all leafs only, therefore MAC based forwarding is not required. This ishighlighted in[5].

In some special scenarios, MAC based forwarding may even introduce some security challenges. This will be furtherdiscussed in later sections.

Second Myth: E-Tree Is Restricted To Broadcast And Multicast Traffic

The second myth is that E-Tree constructs are limited to broadcast and multicast traffic from the root and that theydo not need to support unicast traffic at all.

Lets look at what is stated in the MEF service definition[1]. There are three Service Frame Delivery attributesexplicitly defined, namely Unicast Service Frame Delivery, Multicast Service Frame Delivery and BroadcastService Frame Delivery. Clearly, this does not restrict the type of traffic that can transit over an E-Tree construct.

Again, the different use cases presented before show that unicast traffic, broadcast traffic or a mix of unicast,multicast and broadcast traffic can all be valid traffic transiting over an E-Tree construct.

Third Myth: E-Tree Is Optimized For Broadcast And Multicast Traffic

The third myth is that an E-Tree construct is optimised for broadcast and multicast traffic from the root.

Basically, an E-Tree is an Ethernet service construct only. How the traffic is forwarded within the E-Tree willdepend on the network construct.

If we look at the example of broadcast video in Figure 8, when using E-Line (left), the video source will replicate thevideo content and send one copy per end user to the network. This approach does not help with bandwidthoptimisation.
http://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://metroethernetforum.org/PDF_Documents/MEF6-1.pdf


8/14


Root

LeafLeaf

Leaf

E-Line E-Tree

Carriers

Network

Carriers

Network

Root

LeafLeaf

Leaf

Carriers

Network

Root

Leaf

Leaf

Leaf

Carriers

Network

Option 1

P2P Network Construct replicate at IngressBandwidth Optimisation Not Possible

Option 2

P2MP Network Construct replicate inside Network

Bandwidth Optimisation Possible

Broadcast Video

Multipleservice

instances

Singleservice

instance

Figure 8.Bandwidth Optimisation for Broadcast Video

In contrast, using E-Tree (center), the video source will only send one copy to the root endpoint and let thenetwork do the replication and distribution to all leaf endpoints. There is therefore an opportunity for bandwidthoptimisation inside the network. However, even with the E-Tree construct, bandwidth optimisation may not alwaysbe achieved.

There are at least two further options to construct an E-Tree. In option 1 (top right) the E-Tree construct is basedon point-to-point (P2P) network constructs and packets are replicated at the ingress endpoint towards every leaf.Like in the E-Line case, this does not really bring much bandwidth optimisation (at the exception of the trafficbetween the video source and the root endpoint).

With option 2 (bottom right) the network construct is point-to-multipoint (P2MP) and packets are only replicated atoptimal fan-out points on the path to all leafs. This approach brings full potential for bandwidth optimisation.

Fourth Myth: E-Tree Over MPLS Is Easy And Ready To Go Just Re-Use VPLS WithMinor Changes

The final myth is that E-Tree deployment over MPLS infrastructure is easy and ready to go by just reusing the E-LAN design using VPLS with minor changes.

E-LAN / VPLS

VSI

VSIVSI

VSI

E-Tree (Single Root) /VPLS + Split Horizon

VSI

VSIVSI

VSI VSI

VSIVSI

VSI

Leaf

Root RootRoot Leaf Leaf Leaf Leaf

LeafLeafLeafLeafLeafLeafLeaf

Leaf

MPLSNetwork

MPLSNetwork

MPLSNetwork

S S

S

S S S

S SS S S S S S

S

SSS S

S

Pseudowire (PW) S Split Horizon Group

Problem

R-LR-R

R-L R-L

R-L

R-L R-L R-L

R-R Traffic between Root & RootR-L Traffic between Root & Leaf

R-L

E-Tree (Multiple Roots) /VPLS + Split Horizon

PE4

PE1

PE3

PE2

PE4

PE1

PE3

PE2

PE4

PE1

PE3

PE2

Figure 9.E-Tree over MPLS - reuse E-LAN design using VPLS


9/14


Figure 9 presents a specific scenario of E-Tree where the combination of the current VPLS and PW implementationis not sufficient for the leaf-to-leaf communication restriction.

On the left, an E-LAN design using Virtual Private LAN Service (VPLS) is given. Each edge router holds a VirtualSwitch Instance (VSI) that emulates an Ethernet switch. All these VSIs are fully meshed together via point-to-pointPWs so that they can communicate with each other. One further constraint added (to avoid loops) and detailed in[3]&[4]is that an edge router must not forward traffic from one PW to another PW in the same VPLS mesh.

In the center of Figure 9, a simple E-Tree construct with a single root is presented. To fulfil the leaf-to-leaf

communication restriction, some PWs between VSIs have been removed. Furthermore, an extra constraint (splithorizon group) is added on each edge router to ensure local leafs and PWs to remote leafs do not talk to eachother. With these minor changes, we can successfully build an E-Tree service by reusing the VPLS standards[3]&[4].

The first challenge will arise when several nodes have both root and leaf. This is presented on the right in Figure 9.Edge router PE1 does not know whether a frame received from edge router PE2 via the PW is from a root or a leafon PE2 and therefore whether the frame can be delivered to a local leaf or not.

Even though there are options around this issue (like only having a single root for the E-Tree or attaching leafs androots to different network elements), none of these options present a generic solution to the overall problem.

The second challenge that can be seen from Figure 9 is that with standard VPLS implementation, each edge routeris responsible for replicating the ingress traffic via the use of point-to-point PWs. As explained in the previoussection, such a construct is not optimised for a mix of point-to-point and point-to-multipoint traffic.

The third challenge relates to security issues in multi-subscriber scenarios, such as MAC address spoofing andunknown unicast delivery.
http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4761


10/14


Challenges

Egress Router Does Not Know A Frames Origin On An Ingress Router

One of the key benefits but also a key challenge of E-Tree services is the leaf-to-leaf communication restriction. Asexplained in the previous section, when two or more edge routers have both root and leaf endpoints, in somesituations an egress router does not know whether a frame received on a PW is from a root or a leaf on the ingress

router and therefore has difficulty in enforcing the leaf-to-leaf communication restriction. Several options toaddress this challenge are discussed here.

Derived from Source MAC Address in the Frame

In the current VPLS implementation, the egress router does not know which endpoint on the ingress router a sourceMAC address belongs to. Additional information exchange between edge routers is required, either peer to peer orthrough operation support system (OSS). This involves signalling protocol development or system development,both not simple tasks. On the other hand, due to the dynamic nature of MAC address to endpoint mapping, thisapproach is not considered ideal for security.

Static MAC Address for Root Endpoint

For each root endpoint, static MAC addresses are configured and MAC learning is disabled. A full list of root staticMAC addresses is maintained in every edge router. As anti-spoofing control, at root endpoint only permit ingressframe with source address equal to one of the static MAC addresses of that root, at leaf endpoint deny any ingressframe with source address equal to any of the root static MAC addresses.

The decision on whether a frame is from root or leaf becomes very simple. If a source MAC address matches astatic root MAC address, this means that the frame is from a root endpoint, otherwise the frame is from a leafendpoint.

Obviously, the drawback of this approach is that more configuration changes will be required. However, if we lookat the use cases, the devices connected to root endpoints are not changed often (e.g. Internet gateway router, RAN

NC, PTP Server, video server) and therefore static MAC addresses for root endpoint is considered feasible in mostcases.

This is considered a simple and ready to go option for immediate E-Tree deployment.

Hierarchical VPLS Approach

The Hierarchical-VPLS (H-VPLS) approach relies on a single node doing the split horizon rule (enforce the leaf-to-leaf communication restriction). Basically, all leafs and roots are transported back to a single node that will thenapply locally a split horizon rule.

The first drawback of this approach is that the node doing the split horizon becomes a single point of failure for theE-Tree service. This can be mitigated by using two nodes with split horizon rule and using PW redundancy butobviously with the price of complexity. The second drawback is traffic hair pinning, which potentially cause increasein bandwidth utilisation and also end-to-end latency.

Carry a From Root or Leaf Flag in the Frame

One potential long term solution is to carry a from root or leaf flag per frame on the PW. Currently there is noprotocol standard on where within the frame this flag should be, how the ingress router should set it and how theegress router should act upon it.

One option under consideration is the use of reserved bits in the PW Control Word. This approach requires simpleextensions to current PW and VPLS protocol standards. Relevant Internet drafts are[6][7][8][9].
http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02


11/14


Other Solution Approach

A different solution based on Asymmetric VLAN Shared Learning has also been proposed. This approach alsorequires extensions to current standards. Relevant Internet draft is[10].

Refer toIETF L2VPN working group mailing listfor collaboration happening in IETF.

Bandwidth Optimization

As can be seen from the use cases, some of the E-Tree constructs can be used to distribute the same contentfrom a root to many leafs. This brings a specific challenge to the carrier which is about bandwidth optimisation.

Under the current VPLS and PW standards developed by the IETF, each edge router of an MPLS domain that needsto connect to one or more other edge routers for an E-Tree construct will use a point-to-point (P2P) PW to connectto each remote router. The edge router (where the root is connected) is responsible for replicating towards all theedge routers (where leafs are connected) every Ethernet broadcast/multicast frame coming from the root.

Network Optimisation Options

Figure 10 highlights the network scenario where bandwidth optimisation for broadcast is possible.

P2P PW Optimised

VSI

VSIVSI

VSI

MPLS

Network

PE4

PE1

PE3

PE2

VSI

VSIVSI

VSI

MPLS

Network

PE4

PE1

PE3

PE2

MPLS

Network

PP

VSI VSI

VSI VSI

LeafLeafLeafLeafLeafLeafLeafLeafLeafLeafLeafLeaf

LeafLeafLeafRootLeafLeafLeafRoot LeafLeafLeafRoot

PE1

PE3

PE2

PE4

Broadcast from Root to all Leafs

P2P PW Not Optimised P2MP PW - Optimised

Figure 10.Bandwidth Optimisation for Broadcast

On the left, the PWs are transported on totally different physical paths. In this case no further bandwidthoptimisation can be achieved.

However, in the center, a different physical network topology where the four edge routers are connected via a fifthrouter (P) in the middle, we can see that the three PWs transit via the same physical link between PE1 and P, whichmeans multiple copies of the same content are transported on the physical link. In this case, there is a potential for

bandwidth optimisation in the carrier network.

To address this gap in the current PW toolkit, the IETF has started working on the concept of point-to-multipoint(P2MP) PWs [11] [12]. For simple deployments, the P2MP PWs can be unidirectional, but the IETF is alsodeveloping bidirectional P2MP PWs.

As shown in the right, with P2MP PWs, the edge router is no longer responsible for replicating towards all of theegress edge routers. The network elements along the physical path (router P in this example) can now participatein the replication process. This is achieved via the use of a P2MP PW with the replication done by the underlyinglayer via a P2MP label switched path (LSP).

Even though the prospects of P2MP PWs are attractive to carriers, it is worth mentioning that at the time of this

article, some long term enhancements are still under development (such as dynamic setup, root and leafredundancy, monitoring). This means that in the short term carriers will have to rely on either the classical P2P
http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.htmlhttp://www.ietf.org/mail-archive/web/l2vpn/current/maillist.htmlhttp://www.ietf.org/mail-archive/web/l2vpn/current/maillist.htmlhttp://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.htmlhttp://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00


12/14


approach or a simplified P2MP PW approach that is fully static and manually configured. Relevant RFC and Internetdrafts are[13][14][15].

Refer toIETF L2VPN working group mailing listfor collaboration happening in IETF.

Security In Multi-Subscriber Environment

Some of the important security aspects for an E-Tree service construct have been highlighted in the Internet access

case. This section discusses some of the challenges related to MAC based forwarding in a multi-subscriberenvironment and how they can be addressed in the short term and long run.

The first issue is that sensitive information belonging to a specific customer may also be delivered to anothercustomers location, as illustrated in Figure 11. This is due to the unknown unicast delivery mechanism (i.e.broadcast to all when dont know where to forward) in standard MAC based forwarding.

VSI

VSIVSI

VSI

Leaf-5

Root

Leaf-4

MPLSNetwork

PE4

MAC-4 MAC-5

Leaf-6

MAC-6 MAC-7

Leaf-7

Leaf-2

MAC-2 MAC-3

Leaf-3

MAC-1

Leaf-1

MAC-9

MAC-4

MAC-4

VSI

VSIVSI

VSI

Leaf-5

Root

Leaf-4

MPLSNetwork

MAC-4 MAC-5

Leaf-6

MAC-6 MAC-7

Leaf-7

Leaf-2

MAC-2 MAC-3

Leaf-3

MAC-1

Leaf-1

MAC-9

MAC-4

MAC-4

DA=MAC-4 SA=MAC-9Unicast Frame from Root to Leaf-4

Unicast Known

PE1

PE3

PE2

PE4

PE1

PE3

PE2

Destination address MAC-4 exist in MAC tableof PE1 (source PE) and PE3 (destination PE)

Unicast Unknown

Destination address MAC-4 not exist in MAC table of PE1and PE3 due to MAC aged out or MAC table overflow

The unicast frame is forwarded to the correct endpoint

Leaf-4 (green path) but in addition it is also forwardedto all other Leaf endpoints (red path)

The unicast frame is forwarded to the correct

endpoint Leaf-4 only (green path)

Sensitive Information for MAC-4 Only

Problem

Figure 11.Unicast Frame from Root to Leaf.

The second issue is the well known problem of MAC address spoofing, which also may result in sensitive informationbelonging to one customer being delivered to another customers location. This is due to the MAC address learningmechanism in standard MAC based forwarding.

These issues are only relevant when different customers, mutually un-trusted, are connected to leaf endpoints inthe same E-Tree service (e.g. Internet access). This can be mitigated by inserting a carrier controlled routerbetween the customer network and the leaf endpoint but it is not always feasible.

Immediate requirements and Long term evolutions required

One possible option for immediate deployment is the use of static MAC addresses for leaf endpoints instead of thedynamic MAC address learning. This will resolve both issues mentioned above. Obviously, the major drawback isthe manual configuration that needs to happen. However, as we have explained with the use cases, not all E-Treeare multi-subscriber environment, and in most cases there are only very limited number of MAC addresses per leafendpoint (typically one when a customer router is connected to the leaf endpoint).

The long term approach would be to develop a frame delivery method more secure than the traditional Ethernetdelivery of MAC based forwarding. One option to consider would be the use of VLAN ID as delivery criteria.
http://tools.ietf.org/html/rfc5501http://tools.ietf.org/html/rfc5501http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-06http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-06http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-00http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-00http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-00http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.htmlhttp://www.ietf.org/mail-archive/web/l2vpn/current/maillist.htmlhttp://www.ietf.org/mail-archive/web/l2vpn/current/maillist.htmlhttp://www.ietf.org/mail-archive/web/l2vpn/current/maillist.htmlhttp://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-00http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-06http://tools.ietf.org/html/rfc5501


13/14


Conclusions

This article has focused on the potential benefits and challenges of deploying E-Tree services over an MPLSinfrastructure. E-Tree services appear as good candidates for a wide range of applications, from contentdistribution applications and internet access to wholesale products. The promise is that E-Tree services will easeprovisioning, monitoring, support as well as wholesaling of Ethernet products and will complement the range ofEthernet products offered by carriers today (mainly E-Line and E-LAN) with new offerings.

However, this wide range of use cases brings a set of different requirements on the E-Tree construct, withpotentially several types of E-Tree services having to address very different requirements on the same MPLSnetwork. For example, video distribution and Internet access main requirements (one is about bandwidthoptimisation, the other about security) will drastically differ but both will benefit from an E-Tree service delivery.

On top of that, this article has highlighted some of the short term and long term challenges in the way of successfulE-Tree deployments. While the IETF is currently addressing some of the long term elements with the developmentof VPMS and P2MP PWs, carriers will most likely have to rely on some options using static and manual processes inthe short term.

Some initial thoughts for long term development are also presented in this article, but what this means is that

further work is needed. Collaboration between carriers and vendors as well as extra effort in the different standardbodies are required before carriers can claim that they have truly reached a single converged Carrier Ethernetarchitecture.

Disclaimer: The views expressed in this article are the authors own views only and do not reflect the views of the authors

employers.


14/14


Acknowledgements

The authors would like to thank Lizhong Jin, Lucy Yong, Wim Henderickx and Yuji Kamite for their valuable input and support.

References

[1] Metro Ethernet Forum, Ethernet Services DefinitionsPhase 2, MEF6.1, April 2008.

[2] Martini, et al., Encapsulation Methods for Transport of Ethernet over MPLS Networks, RFC4448, April 2006.

[3] Kompella & Rekhter, Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling, RFC4761, January2007.

[4] Lasserre & Kompella, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, RFC4762,January 2007.

[5] Kamite, et al., Framework & Requirements for Virtual Private Multicast Service (VPMS), draft-ietf-l2vpn-vpms-frmwk-requirements-02, work in progress, October 2009.

[6] Key, et al., A Framework for E-Tree Service over MPLS Network, draft-key-l2vpn-etree-frwk-02, work in progress, March2010.

[7] Key, et al., Requirements for MEF E-Tree Support in VPLS, draft-key-l2vpn-vpls-etree-reqt-00, work in progress, April 2010.

[8] Key, et al., Extension to VPLS for E-Tree, draft-key-l2vpn-vpls-etree-02, work in progress, January 2010.

[9] Delord, et al., Control Word Reserved bit for use in E-Tree, draft-delord-pwe3-cw-bit-etree-02, work in progress, January2010.

[10] Jiang, VPLS PE Model with E-Tree Support, draft-jiang-l2vpn-vpls-pe-etree-00, work in progress, March 2010.

[11] Jounay, et al., Requirements for Point-to-Multipoint Pseudowire, draft-ietf-pwe3-p2mp-pw-requirements-02, work inprogress, January 2010.

[12] Martini, et al., Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP, draft-martini-pwe3-p2mp-pw-01, work

in progress, October 2009.

[13] Kamite, et al., Requirements for Multicast Support in Virtual Private LAN Services, RFC5501, March 2009.

[14] Raggarwa, Kamite & Fang, Multicast in VPLS, draft-ietf-l2vpn-vpls-mcast-06, work in progress, March 2010.

[15] Delord, et al., Extension to LDP-VPLS for Ethernet broadcast and multicast, draft-delord-l2vpn-ldp-vpls-broadcast-exten-01, work in progress, May 2010.
http://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://metroethernetforum.org/PDF_Documents/MEF6-1.pdfhttp://tools.ietf.org/html/rfc4448http://tools.ietf.org/html/rfc4448http://tools.ietf.org/html/rfc4448http://tools.ietf.org/html/rfc4448http://tools.ietf.org/html/rfc4448http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/rfc5501http://tools.ietf.org/html/rfc5501http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-06http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-06http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-06http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-01http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-01http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-01http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-01http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-01http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-01http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-01http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-01http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-06http://tools.ietf.org/html/rfc5501http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-martini-pwe3-p2mp-pw-01http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-02http://tools.ietf.org/html/draft-jiang-l2vpn-vpls-pe-etree-00http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-delord-pwe3-cw-bit-etree-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-02http://tools.ietf.org/html/draft-key-l2vpn-vpls-etree-reqt-00http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-02http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://tools.ietf.org/html/draft-ietf-l2vpn-vpms-frmwk-requirements-02http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4762http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4761http://tools.ietf.org/html/rfc4448http://metroethernetforum.org/PDF_Documents/MEF6-1.pdf