Metro Ethernet: Understanding Key Underlying Technologies

Metro Ethernet: Understanding Key Underlying Technologies
Metanoia, Inc. Critical Systems Thinking™ Metro Ethernet: Understanding Key Underlying Technologies Metanoia, Inc. © Copyright 2007 All Rights Reserved

Who is Metanoia, Inc.? Specialty technology consultancy founded in mid-2001, with HQ in Mountain View, California Undertakes deep-dive technical consulting in telecom network, systems, software and chip architecture and design for clients across the world Services have spanned 4 continents, with clients in: North America, Europe, Asia, and Australia. Principals provided services in technology strategies, architecture and design trade-offs, product development, hardware/software architecture, and knowledge enhancement to organizations that include large equipment manufacturers, international, national and regional ISPs, premier metro/access systems startups, network planning tool vendors, established software and technology houses and leading component and semiconductor vendors Principals are technologists at the forefront of new developments, as leaders, creators, implementers, researchers, academics, strategists, and advisors in the US and abroad Expertise spans Layer 1 through Layer 4, and wireline (optical, Ethernet, IP/ATM, SONET/SDH) through wireless (Wi-Fi, cross-layer design, Wi-Max, cellular data, 2.5-3G) 125+ man years of technology design and development, and technology management experience, having worked at leading global corporations, such as Apple, AOL Time Warner, BBN, Cisco, 3Com, Fujitsu, LSI Logic, Motorola, Tellabs, Siemens, Nokia, Tibco, and Qualcomm, and having worked at/consulted to corporates in the US and abroad for almost the last decade 70+ patents collectively issued/pending Advanced graduate degrees from some of the most distinguished universities in the world – the University of California, Stanford University, Iowa State University, the University of Texas, the University of Waterloo, and the Indian Institute of Technology Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Workshop Outline Legacy networks & Ethernet over legacy networks
Value propositions and business drivers Ethernet over SDH/SONET Metro Ethernet Forum (MEF) MEF architecture E-Line and E-LAN services Native Ethernet as Carrier-class transport Provider Bridges Provider Backbone Bridges (PBB), Provider Backbone Transport (PBT) MPLS – an enabler for Ethernet services Layer 2 VPNs: VPWS, VPLS, H-VPLS Advanced concepts: traffic engineering, QoS, OAM, resilience Conclusions Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Ethernet over Legacy Networks
Metanoia, Inc. Critical Systems Thinking™ Ethernet over Legacy Networks

Issues with Legacy Networks
Low bandwidth No flexibility to scale High cost of installation Slow provisioning Bandwidth growth inflexible/non-linear Limited by multiplexing hierarchy TDM-based access: inefficient for converged data Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Next-Generation SDH Customer Network TDM Ckt Customer Network
Central Office Switch NG-SDH NG ADM TDM Ckt Core Network NG-SDH Ethernet Customer Network NG ADM STM/4/16 Ring Cross Connect TDM Ckt NG-SDH NG ADM Customer Network Ethernet Customer Network Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India 6

Ethernet-over-SDH Framing protocol
Encapsulates Ethernet frames in SDH payloads Mapping of SDH payload to SDH channels Virtual concat.: for allocation of non-contiguous VCs Flow control mechanism Avoids packet drops due to speed mismatch between SDH and Ethernet Mechanism to increase/decrease allocated SDH bandwidth Add or remove VCs Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Ethernet-over-SDH (contd)
Very popular in carriers with installed base of SDH rings E.g. BSNL in India Good deployment choice when traffic primarily circuit switched Inefficient if major traffic is bursty packet-switched data Solution: Carrier-class Ethernet! Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Metro Ethernet Value Propositions
Lower per-user provisioning costs Technically simple relative to TDM ckts. Due to large installed base Efficient and flexible transport Wide range of speeds: 128 Kbps--10 Gbps QoS capabilities Ease of inter-working Plug-and-play feature Ubiquitous adoption The technology of choice in enterprise networks Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Ethernet Business Drivers
Business connectivity Storage networks Data centers Video conferencing Residential services Triple-play services (IPTV) On-line gaming High-speed Internet access Wireless backhaul Reduced cost, complexity for mobile operators Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Metro Ethernet Services
Metanoia, Inc. Critical Systems Thinking™ Metro Ethernet Services

Metro Ethernet Forum (MEF)
Industry forum at forefront of Carrier Ethernet standardization Carrier Ethernet architecture Ethernet services Founded in Currently approx. 120 members Technical Sub-committees Architecture Services Protocols and Transport Management Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

MEN Architectural Components
End User Customer Network MEN S T UNI Reference Point Ethernet Virtual Connection End-to-End Ethernet Flow End user Interface Ethernet Flow Unidirectional stream of Ethernet frames UNI Interface used to interconnect MEN subscriber to provider EVC Defines association between UNI for delivering Ethernet flow across MEN Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India 13

Application Service Layer
MEN Layer Model Application Service Layer (IP, MPLS, PDH, E1/E3, SDH) Ethernet Service Layer Transport Service Layer (802.1, SONET/SDH, MPLS) MEN Layer Model Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

MEF Services Definition Framework
Service Type Construct used to create broad range of services Service Attributes Defines characteristics of a service type Attribute Parameters Set of parameters with various options Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Service Types E-Line E-LAN
Point-to-point Ethernet Virtual Circuit (EVC) E-LAN Multipoint-to-multipoint Ethernet Virtual Circuit EVC1 EVC2 Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India 16

Service Attributes Physical Interface Traffic Parameters
Medium, speed, mode, MAC layer Traffic Parameters CIR, CBS, PIR, MBS QoS Parameters Availability, delay, jitter, loss Service Multiplexing Multiple instances of EVCs on a given physical I/F Bundling Multiple VLAN IDs (VID) mapped to single EVC at UNI Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Ethernet Services Ethernet Private Line (EPL)
Uses E-Line Does not allow service multiplexing High degree of transparency Low delay, delay variation, and packet loss ratio Ethernet Virtual Private Line (EVPL) Allows for service multiplexing Need not provide full transparency Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Service Types and Ethernet Services
Based on the MEF and IEEE classification, one can divide types of Ethernet service into the following 4 types. E-line- p2p connectivity – E.g. Used for Ethernet private line, Internet access, and p2p Ethernet VPNs. E-LAN- p2mp connectivity. E.g. Used for mp2mp Ethernet VPNs, Ethernet Transparent LAN service. Within E-line there is Ethernet Private Line – provided by a dedicated p2p circuit, with fixed, unshared bandwidth. Ethernet Virtual Private Line – provided by a multiplexed p2p circuit, with shared bandwidth. Ethernet Private LAN – provided by p2p circuits realizing mp2mp connectivity, with dedicated, unshared bandwidth. Makes a Metro-Ethernet Network appear like a LAN. Ethernet Virtual Private LAN – providing mp2mp connectivity over a shared infrastructure. Can be realized via shared, p2p circuits between endpoints. Ethernet Services Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Native Ethernet as Carrier-class Transport
Metanoia, Inc. Critical Systems Thinking™ Native Ethernet as Carrier-class Transport

Requirements for Carrier-class Ethernet
Scalability Network should support millions of subscribers Protection and restoration 50ms resilience Quality-of-Service (QoS) Ability to offer differentiated levels of service Service Monitoring and Fault Management Support for TDM traffic Seamless integration with legacy networks Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Ethernet Ring Customer Network Customer Network Ethernet Switch
Core Network Ethernet 1/10 Gigabit Ethernet Ring Ethernet Switch Customer Network Ethernet Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Native Ethernet in Metro Access
How does one create the notion of a virtual circuit? VLAN tagging with point-to-point VLAN VLAN stacking Outer tag  service instance; Inner tag  individual customer 802.1Q in 802.1Q (Q-in-Q) - IEEE 802.1ad C-DA C-TAG C-SA Client data FCS S-TAG 6bytes 4bytes C-DA: Customer Destination MAC C-SA: Customer Source MAC C-TAG: IEEE 802.1q VLAN Tag C-FCS: Customer FCS S-TAG: IEEE 802.1ad S-VLAN Tag Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Provider Bridge (IEEE 802.1ad) Architecture
CE-B CES Customer Network Customer Network CE-A UNI-B CES UNI-A CES Spanning tree UNI-C CE-C CE: Customer Equipment UNI: User-to-Network Interface CES: Core Ethernet Switch/Bridge P-VLAN: Provider VLAN Customer Network Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India 24

Limitations of Provider Bridge Scalability
Limited to 4096 service instances Core switches must all MAC addresses Broadcast storms ensue due to learning MAC address tables explode! Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Provider Backbone Bridging (802.1ah)
Encapsulate customer MAC with provider MAC at edge Edge switch adds 24-bit service tag (I-SID), not VLAN tag Core switches need only learn edge switch MAC adds. B-DA B-TAG B-SA I-TAG C-DA C-TAG C-SA Client data B-FCS 6bytes 4bytes 5bytes S-TAG: IEEE 802.1ad S-VLAN Tag B-DA: IEEE 802.1ah Backbone Destination B-SA: IEEE 802.1ah Backbone Source MAC I-TAG: IEEE 802.1ah Service Tag Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Provider Backbone Bridging (PBB) Architecture
CPE A CPE B CPE B CPE A CPE D CPE C Provider backbone network (802.1ad) Provider backbone network (802.1ad) 802.1ad Provider backbone network (802.1ah) Provider backbone network (802.1ad) Provider backbone network (802.1ad) 802.1q CPE C CPE B CPE A CPE B CPE D CPE C Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Benefits of PBB Scalability Robustness Security Simplicity
Addresses limitations of 4096 service instances Robustness Isolates provider network from broadcast storms Security Provider need switch frames only on provider addresses Simplicity Provider & customers can plan networks independently Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Traffic Engineering in PBB
Via Multiple Spanning Tree Protocol (MSTP) Maps a VLAN to ST or multiple VLANs to ST Enables use of links that would otherwise be idle in ST Eliminates wasted bandwidth … but … Too slow for protection switching Not suitable for complex mesh topologies Difficult to predict QoS Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Challenges with an All-Ethernet Metro Service
Restriction on # of customers – 4096 VLANs! Service monitoring Scaling of Layer 2 backbone Service provisioning Carrying a VLAN is not a simple task! Inter-working with legacy deployments Restriction on# of customers: carriers limited to 4096 customers. Even with Q-in-Q, the carrier is still restricted to 4096 global VLAN IDs within its network. While this number may be ok for experimentation, it is not appropriate for a large scale service! Service monitoring: There is not embedded service monitoring in Ethernet today. Thus, additional control plane intelligence is required to enable this. For instance, the Ethernet Virtual Connection service and associated parameters defined by MEF, require new protocols to meaningfully extract relevant performance parameters, and present it in a useful way. Today L2 backbones are limited by STP scalability. One problem with the STP is that it is designed fundamentally to prevent loops. Thus, it makes traffic flow depended on loop prevention rather than resource/bandwidth optimization. Carrying a VLAN through the network is not a simple task! A new VLAN today requires the careful configuration/coordination of VLAN IDs on all switches participating in the VLAN. There is no signaling protocol support to do so, thus task is manual, error-prone and tedious! Interworking with FR and ATM. How to connect new sites with Ethernet access with older sites/HQ enabled with FR/ATM. What if one end is bridged and the other is routed? RFC 2427 describes how to carry multi-protocol over FR, needs several inter-working functions, complicating things. By using a hybrid architecture, one may constrain the L2 Ethernet network to the access, where the inefficiencies of STP and VLAN limits are more controlled and limited. The core can be an IP/MPLS network. (In a L2 service, the carrier offers its customers the ability to transparently overlay their own networks on top of the carrier’s network.) Need hybrid architectures … Multiple L2 domains connected via IP/MPLS backbone Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

What Solutions do we Have?
Ethernet-based Architecture Provider Bridge (802.1ad) in edge Provider Backbone Transport (PBT) in Core Hybrid Architecture 802.1ad in the edge Multiprotocol Label Switching (MPLS) in core Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Provider Backbone Transport (PBT)
Connection-oriented, traffic-engineered Ethernet tunnels Replaces spanning tree control plane with either a: Management plane External control plane No learning ! Forwarding info. provided by management plane Forwarding done on MAC + VID (60-bit) address VID is not network global; however, MAC + VID is B-MAC identifies destination B-VID identifies per-destination alternate paths Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

PBT Architecture Central TE Module Customer Customer Network Network
PE2 PE1 Customer Network Customer Network SA : PE1 DA : PE2 VLAN 22 SA : PE1 DA : PE2 VLAN 33 Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India 33

Benefits of PBT No learning Protection QoS support available
Eliminates undesirable broadcast storms Resolves MAC flooding problem Addresses scaling by forwarding on MAC + VID-highly scalable Protection Sets-up backup paths 50ms restoration possible QoS support available Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

MPLS – An Enabler for Ethernet Services: Fundamentals & Operations
Metanoia, Inc. Critical Systems Thinking™ MPLS – An Enabler for Ethernet Services: Fundamentals & Operations

Basic Concept of MPLS Routing fills routing table
x 1 x.x 2 Label Table X x 3 1 x.x 4 3 4 x 5 1 x.x 7 2 R3 Advertises binding <5, x> R1 R2 Advertises bindings <3, x> <4, x.x> Advertises binding <7, x.x> Routing fills routing table Signaling fills label forwarding table R4 Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Basic Concept of MPLS 128.89.10.x 1 179.69.x.x 2 128.89.10.12
5 Pop label Forward packet X x 3 1 x.x 4 x 1 x.x 2 3 3 4 x 5 1 5 5 Swap Label x.x 7 2 R3 5 3 R1 R2 3 Push Label Packet arrives DA= R3 R4 Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

So what about MPLS Control and Forwarding?
Superset of conventional router control Distribute info. via n/w layer routing protocols (OSPF, BGP, etc.) Algos. to convert routing info. into forwarding table: Create binding from FEC  label Assign & distribute labels to peer LSRs via signaling Label switching forwarding table (or label information base LIB) Forwarding algo = label swapping, independent of control component (implementable in optimized H/W or S/W) Control Component Incoming Label Map First Subentry Second Subentry (for multicast or load balancing) Outgoing label Outgoing inf. Next hop address Outgoing label Outgoing inf. Next hop address Incoming Label Forwarding Component Next hop label forwarding entry (NHFLE) Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

What does a Label Represent? The Issue of Label Granularity
Packets form Forwarding Equivalence Class (FEC) Treated identically by participating routers Assigned the same label Membership in FEC must be determinable from IP header + other info. that ingress router has about the packet Entities that may be grouped into an FEC are flexible. E.g. FEC could be: Connection between two IP ports on two hosts or between IP hosts Traffic headed for a particular network with same TOS bits All destination networks with a certain prefix Manually configured connection Traffic belonging to a customer or department VLAN Traffic of a given application – voice, video, plain data, management traffic … and many others Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Let’s Recap: Elements of MPLS
Label Forwarding Use data link addressing. E.g. ATM VPI/VCI, FR DLCI “Shim” header between data link and IP header Label Creation and Binding Label Assignment and Distribution Ride piggyback on routing protocols, where possible (BGP) Separate label distribution protocol – RSVP, LDP Data Plane 1 bit Control Plane Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Primary Label Assignment and Distribution Modes
1 Requests Edge LSR 2 6 3 5 4 Assignments Downstream-on-demand with Ordered Control Edge LSR Edge LSR 1 Requests 2 2’ Assignments 3 3’ 4 Downstream-on-demand with Independent Control Edge LSR Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Advantages of MPLS Original justification Current justifications
Availability of fast, amortized, ATM hardware; emergence of H/W forwarding engines has practically eliminated this Current justifications Separates forwarding from control, allowing Routing functionality to evolve independently of forwarding algorithm MPLS to control non-packet technologies: SONET/SDH ckts., lightpaths Provides explicit, manageable IP routes Enables policy routing and traffic engineering Offers TE for Ethernet tunnels in metro-Ethernet environments Facilitates scalable hierarchical routing Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

The Utility of Hierarchical Label Switching
Edge LSRs Swap Swap and Push Core LSRs Pop Concept is similar to VLAN stacking in PBT we saw earlier Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Hierarchical Label Stacking/Switching
Inside a transit AS, each core router must keep track of all networks that might be reached through it With hierarchical labels, only edge routers need know what networks might eventually be reached through them All transit traffic can be made to tunnel through core routers using LSPs with stacked labels Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Explicit Manageable Routes -- Policy routing, Traffic engineering
Carriers want certain traffic to go over certain routes. Such network engineering: Keeps network loads balanced Enhances network stability and reliability Enables better QoS and performance assurances Allows carriers to meet customer SLAs Constraint-based routing together with MPLS allows carriers to Bind Ethernet tunnels to an LSP, Place (or route) LSP over the desired sequence of LSRs in the n/w TE tunnels are helpful for VPLS-based carrier Ethernet n/ws Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

IP/MPLS-based Layer 2 VPNs
Metanoia, Inc. Critical Systems Thinking™ IP/MPLS-based Layer 2 VPNs

What does the P1-PE2 connection really look like?
L2 VPN Components What does the P1-PE2 connection really look like? At its core an L2 VPN realized over an IP network can either provide a p2p service, as a replacement of traditional L2 VPN provided by FR and ATM, or a mp2mp service, as a replacement for a switched Ethernet service provided in traditional Ethernet networks. The provider core devices (VPLS devices) provide a logical interconnect such that the CE devices in a specific VPN appear to be on a single bridged Ethernet. As seen here, CE devices connect to PE routers via attachment circuits of various types. The PE routers in turn are connected by PWs running over tunnels, and form a virtual backbone that functions like a LAN. But what do the details of the PE1-PE2 connection look like? We see that next … Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

L2 VPN Component Details
Here I’ve illustrated the key components of L2 VPNs, whether VPWS or VPLS. 1. The first are the AC’s that connect the CE switches/routers to the PE’s. These can be FR DLCI, ATM VCs, Ethernet port, Ethernet VLAN, PPP connection, PPP session in L2TP, MPLS LSP, and carries a frame from CE to PE. 2. The AC’s attach to a bridge module in the PE, which attaches via an emulated LAN interface to a forwarder. The forwarder modules are connected via PWs that travel over a PSN tunnel over a routed backbone. The bridge module functions as a std. Bridge, learning MAC addresses on the AC’s and possibly running SPT. 3. The Forwarder on receipt of a frame from an incoming AC over the emulated LAN interface, determines the outgoing PW, based on the incoming AC, the L2 header, and provisioned parameters. 4. The PWs are a pair of unidirectional VCs that originate/terminate at peer PE’s. They provide encapsulation of service-specific PDUs Help in managing the signaling, timing, and order of PDUs Coordinating/conveying service-specific status and alarms. 5. The PSN tunnel carries PW PDUs across the backbone, and can carry multiple PWs. Any tunneling technology with a demultiplexing field to identify the PW can be used. 6. Finally, there is PW signaling, which is essentially responsible for the exchange of the PW demultiplexer between PE’s, thus “setting up” the PW. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

VPLS Network Overview VPLS is an L2VPN that emulates a LAN, and provides full learning and switching capabilities. This is done by allowing PE routers to forward Ethernet frames based on the MAC addresses of the end stations that belong the the VPLS. There is full mesh of tunnels and PWs connecting the PE routers involved in a given VPLS, as shown here. Each VSI or forwarder maintains a table mapping MAC addresses to PWs. Performs MAC source address learning for frames received on the PWs. (The bridge module discussed earlier performs MAC address learning for frames received from AC’s.) It also does address aging, and split horizon for loop prevention. The bridge module attached to each VSI (not shown here), does MAC learning on ingress AC’s and may run SPT over the emulated LAN. The PE device is any edge router capable of running a signaling/routing protocol to setup PWs, and to setup transport tunnels to other PE’s to deliver PW traffic. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

VPLS Protocols Involved
There are two sets of protocols to consider. Those in the control plane and those in the data plane. The control plane involves 2 control subflows: -- Exchange of PW labels across the backbone -- Establishment/assignment of tunnels for PW transport Explain the protocol combinations in the control plane that can be used – Targeted LDP and BGP. And LDP or RSVP-TE for tunnel setup. Talk a bit about the protocols and encapsulations in the data plane. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Operational Characteristics of VPLS
Learning and forwarding based on MAC address, and switching of packets between tunnels based on MAC addresses, plus interworking with IEEE p/q tags and VLANS – achieved by the VSI forwarded and bridge modules per VPLS Support flooding of packets with unknown, broadcast,and multicast addresses, and replicate frames only to those VPLS devices that are part of the same VPN – via frame replication on PWs PE’s must be informed to auto-configure, and must learn of membership, tunneling etc. – via signaling protocols, targeted LDP or BGP. Membership discovery – via BGP or configuration Inter-provider connectivity should be possible: achieved by having a globally unique VPLS ID. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Data Plane: Flooding, Address Learning and Forwarding
All address unknown frames (unicast, multicast, broadcast) flooded over corresponding PWs to all relevant PEs only Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Address Learning Layer 2 reachability directly learned in data plane
Use standard learning bridge functions for local MACs PW-based association for remote MACs Allow PE to determine from which physical port or LSP a given MAC address came VSI FIB keeps mapping between Ethernet MAC  PW to use Qualified Learning Unqualified Learning - Each customer VLAN is its own VPLS instance - Has its own PW mesh and brdcast domain - All customer VLANs are part of the same VPLS - One PW mesh and single brdcast domain Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Address Learning Example
LDP signaling of VC labels for LSPs comprising the PW. Broadcast packet from a station arrives at PE1, the bridge module of PE1 associates Src= SA1 with the incoming/outgoing I/F 1 or port 1 or VLAN that the frame came on. PE1 recognizes (by configuration) that the frame belongs to VPLS A, and replicates it, transmitting along VC LSPs to PE2 and PE3. PE2 on receiving the frame on inbound VC LSP, associates that MAC with the remote end of the corresponding outbound VC LSP of the VC LSP pair that constitutes the PW between PE1 and PE2. Each PE signals different labels to its peers, so it can always distinguish between inbound frames from different PE’s. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Forwarding and Encapsulation
Forwarding requires ability to Dynamically learn MAC addresses on Physical ports Pseudowire VCs (VC LSPs) Forward/replicate pkts. across physical ports and VC LSPs Encapsulation PW header applied to Ethernet packet w/o preamble + FCS VLAN tag denoting customer’s VPLS instance can be stripped at ingress, reapplied at egress The VLAN tag can be stripped, because it is assigned by the provider and known within the VPLS. As a result, it can be reapplied at the egress PE corresponding to a given VPLS. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Tunnel and PW Topology and Loop Freedom
This example shows how a full-mesh of PWs and tunnels, together with split-horizon forwarding provides loop freedom. Full mesh of PW and tunnels deployed Tunnels Help transport the PW payload Aggregate traffic from multiple PWs Pseudowires – demultiplex the L2 traffic traversing tunnels Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Scaling VPLS: Hierarchical VPLS
Base VPLS requires full mesh of VC LSPs between PE routers Adequate for PE routers in CO – multiple customers aggregated Inadequate for PE routers in MTU basements! Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Hierarchical VPLS Advantages
Benefits Simplifies signaling Reduces pkt. replication Simplifies MTU Scalable inter-domain VPLS Simplifies new site addition Simplifies signaling because amount of signaling goes down by as much as an order of magnitude! The full mesh between MTU routers, reduces to a mesh only between core PE’s and spoke VLLs. Reduces packet replication, since no replication is needed at MTU, except for local switching. The MTU cost comes down due to reduced computing requirements on it. Inter-domain connections can be realized via a single spoke, as opposed to a slew of VC LSPs. Addition of a new site only impacts the associated PE, and none of the other sites. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Hierarchical VPLS: Case Study for a Metro Region
100 MTUs; 10 customers/MTU; 2 VPLS/cust.; 100 stations/VPLS VPLSs/MTU = 10x2 = 20 MACs/MTU = 20x100 = 2000 So, the number of LDP/BGP sessions to be supported comes down by two orders of magnitude. The number of MACs to be supported on a PE does increase by one order of magnitude, but that is still manageable. Later, we’ll see other architectural solutions to simplify this design, and divide the work between the core PE’s and the MTU PE’s appropriately. No hierarchy  PE supports 2000 MACs LDP/BGP sessions = (100x99)/2 x 20 = 245,000 Hierarchy (10 MTU/PE)  PE supports 2000 x 10 = 20,000 MACs LDP/BGP sessions = (10x9)/2 x 200 = 9000 # of spoke VLLs = 10 x 20 = 200 Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Benefits of IP/MPLS-based L2 VPNs
Separation of administrative responsibilities Migration from traditional L2 VPNs: seamless transport of Ethernet services Privacy of routing Layer 3 independence Less operational overhead Ease of configuration (?) Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Advanced Features: Traffic Engineering, Resilience, OAM, QoS
Metanoia, Inc. Critical Systems Thinking™ Advanced Features: Traffic Engineering, Resilience, OAM, QoS

Traffic Engineering Concepts
Metanoia, Inc. Critical Systems Thinking™ Traffic Engineering Concepts © Copyright 2006 All Rights Reserved

Constraint Based Routing
A class of routing systems that computes routes through a network subject to a set of constraints and requirements QoS-based Routing Path of flows determined by Knowledge of resource availability in network QoS requirements of flows Policy-based Routing Path/routing decision based on administrative policy Good afternoon! And welcome to the course on next-generation high-performance switch architectures. Thank you for coming. Over these two days my goal is to explore some details of this subject that will lead to a deeper understanding of the operation of canonical high-speed switch architectures. Before we begin, I’d like to give you a quick overview of the course, and of the sequence in which we’ll cover the material. The material is organized into 6 parts, half of which we’ll cover today. Today, we’ll begin with an overview of some basic switching notions and look at the essential architectural components of switches and cross-connects. We’ll also look at the generic data path processing that occurs within each. We will then look at a taxonomy of switch architectures and switching fabrics. Here we’ll cover the evolution of switch/routers over several generations, and examine the properties and features of different types of switching fabrics. We’ll also review the properties of input and output queueing. Having developed an overall understanding of the architectures of switches and routers, we’ll delve next into tracing the data path through an IP router, a TDM cross-connect, and a hybrid TDM/IP switch, and look at two examples in detail – the Cisco Catalyst switch and the Juniper M Series routers. Starting tomorrow, we will start dissecting each of the three main processing steps in a switch/router--- input processing, scheduling across the switch fabric, and output queuing. We’ll look at methods, algorithms, and techniques for each with a focus on hardware complexity and implementation issues. I have factored in time for discussions, so I hope you’ll ask questions freely at any time during these lectures. This will enable me to adjust my presentations to best help you. It will also make these lectures more interesting for me. If you have additional questions, please feel free to contact me after May 6th. My contact information is on the title slide. Can be on-line or off-line Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

CB Routing System Inputs Outputs
Flow/path attributes: required b/w, hop count, ... Resource attributes: properties of nodes/links Network topology & state Outputs Computed feasible path Explicit route of the path Path computation  To compute path while honoring constraints (E.g. CSPF) Need info. at source or central location Enhanced Routing  To distribute info. about network topology and link attributes Enhanced Signaling  Establish forwarding state Reserve resources along path Modify link attributes resulting from reservations Mechanism to support forwarding along path  Support for explicit routing, or MPLS as a forwarding mechanism Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

MPLS-based Resilience for the Metro
Metanoia, Inc. Critical Systems Thinking™ MPLS-based Resilience for the Metro © Copyright 2006 All Rights Reserved

Fundamental Characteristics of RSVP
Allows apps. to signal QoS requests to n/w, and n/w to respond with success or failure Designed to transport Classification info. (Sender_Template) Allows flows with specific QoS reqs. to be recognized Traffic specs of source/sender (Tspec) QoS needs of receivers (Rspec) Soft-state protocol Path/Resv transmitted periodically to refresh reservation Refresh Reduction [RFC2961] has practically eliminated original scalability concerns with use of soft state Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Basic Operation of RSVP-TE
Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Fast Re-Route (FRR) using RSVP-TE
Rerouting is done when A better path is available Upon failure along LSP Use SESSION Obj. & SE style Tunnel uniquely identified by Destination IP address Tunnel ID Ingress IP address Tunnel ingress made to appear as 2 different senders to the RSVP session (via LSP ID) Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

TE with Constraint-based Routing in a Nutshell
Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

How it All Fits Together
Since each remote CE must be able to pick a DLCI and a VPN label to communicate with the advertising CE. The VPN label needs to be separate for each remote CE because its traffic must uniquely map to a DLCI on the local PE-CE link. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Why Ethernet OAM? Current management protocols lack per-customer granularity to handle Ethernet services Most management protocols operate are point-to-point Ethernet OAM can exploit multipoint capability Link management required for last-mile connection Similar to link mgt. in FR and ATM Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Ethernet OAM Types Service OAM Link OAM
e2e connectivity and fault mgt. per service instance Part of IEEE 802.1ag, CFM project Link OAM Monitoring & fault mgt of individual Ethernet link (physical/emulated) Part of IEEE 802.3, Clause 57 (formerly 802.3ah (not to be confused with 802.1ah)) Ethernet Local Mgt. Interface (E-LMI) Configuration & operational provisioning of customer edge device Part of MEF Standard MEF-16 Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Service OAM Works on per-EVC basis CFM messages
Independent of underlying transport technology CFM messages Continuity Check Message Detects loss of service connectivity Link Trace Message Traces the path hop-by-hop (like IP traceroute) Loopback Message Detects whether target point is reachable (like ICMP Ping) AIS (Alarm Indication Signal) Message Asynchronous notification to indicate fault Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Link OAM Discovery Link Monitoring Remote Failure Indication
Identifies devices at both ends of the link Link Monitoring Detects link faults Statistics of packet errors Remote Failure Indication Conveys loss-of-signal indication to peers, due to poor SNR, power failure, or other critical events Remote Loopback Determines quality of link during installation and troubleshooting Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

E-LMI Provides local configuration & operational parameters to customer edge VLAN-EVC mapping QoS profiles of EVC Reduces configuration errors, improves performance Dynamic EVC management Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

MPLS and Quality-of-Service for Ethernet Services
MPLS supports (not extends) a packet-based QoS model MPLS does not run in hosts (only in metro/core routers) QoS, however, is an end-to-end mechanism MPLS helps carriers offer QoS-enabled services efficiently Can support MEF QoS model via DiffServ QoS framework Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Differentiated Services Framework
Traffic flows aggregated into small # of classes Per-flow state is not required More scalable than IntServ Drop Precedence Class Priority DSCP EF 101110 AF1x 001xx0 AF2x 01xx10 AF3x 11xx10 AF4x 1xxx10 1 2 3 BE Class encoded in IP header via DiffServ Code Point (DSCP) Edge router … Classifies packets to DifServ classes DSCP identifies Per Hop Behavior (PHB) Best Effort (BE) Expedited Forwarding (EF) Minimal delay & loss Assured Forwarding (AF) 4 classes 3 drop precedence’s each 12 possibilities total Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Differentiated Services Architecture
Diffserv performs complex QoS functions such as classification, marking, metering, and shaping/policing at the edge, as far as possible, and performing queuing and scheduling in the network core. Traffic is classified and marked with the DSCP into a small number of traffic classes. In the core, scheduling/queuing is applied to the traffic classes based on the DSCP field; and any conditioning and dropping is also handled based on the DSCP. A traffic profile: specifies some properties of traffic that is to receive a certain level of service. The packet classifier helps to select flows that will receive a given service. It may be a simple one based on the DS byte or a complex multi-field classifier. The latter can distinguish between traffic from different flows arriving in the same interface but covered by separate SLAs. The meter monitors each substream identified by the classifier, typically via a logical token bucket/leaky bucket mechanism, configured with the parameters of the flow, and identifies packets as in-profile or out-of profile. The marker causes a packet to be treated per the SLA/TCA, by setting the value in the DS byte of the IP header, based on the classifier and metering function. This value determines the PHB to be received by packets within the domain. The shaper/dropper ensures that flows conform to the parameters of the particular traffic profile, and may cause some packets to be delayed/discarded to enable conformance with the profile. In the core, the packet is queued appropriately, and serviced by an appropriate scheduler. The PQ always serves the EF queue first, and seeks a packet from the WFQ scheduler when the EF queue is empty. The WFQ selects packets from the remaining queues, based on the weights allocated to them, and can follow a number of algorithms – CBQ, DRR, WRR, etc. Colored packet (marked DSCP) Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

MPLS Support of DiffServ: Mapping DSCPs to LSPs (or labels)
Map DSCP  EXP bits in MPLS “shim” header 6 DS bits (64 PHBs) and only 3 EXP bits (8 classes)! Complete mapping is infeasible For many practical cases, 8 PHBs may suffice Results in an LSP called an E-LSP IP Header MPLS “shim” header 6 bits DSCP DSCP Label EXP S TTL -- Packets belonging to different PHBs but belonging to the same PHB scheduling class should not be misordered -- Packets of a common PHB scheduling class must travel on the same LSP -- How to determine different PHBs of a PHB scheduling classs? -- Take the help of EXP bit One observation if the network supports fewer than 8 PHB then we can use EXP bits An LSP set up under these conditions is called E-LSP What if we need more than 8 PHB? We need to provide information inside labels This requires enhancing Label Distribution Protocol also Label can now be bound to both <FEC, PHB> DS byte 3 bits Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

MPLS Support of DiffServ: Mapping DSCPs to LSPs (or labels)
Map {PHB, FEC}  MPLS Label That is, provide the info. in the label itself! Requires enhancing the label distribution protocols Use EXP bits for drop precedence That is to determine different PHBs of a PHB scheduling class Label EXP TTL S DSCP 6 bits 3 bits DS byte DS class drop precedence DS class: EF, AFx IP Header MPLS “shim” header One observation if the network supports fewer than 8 PHB then we can use EXP bits An LSP set up under these conditions is called E-LSP What if we need more than 8 PHB? We need to provide information inside labels This requires enhancing Label Distribution Protocol also Label can now be bound to both <FEC, PHB> -- Packets belonging to different PHBs but belonging to the same PHB scheduling class should not be misordered -- Packets of a common PHB scheduling class must travel on the same LSP -- How to determine different PHBs of a PHB scheduling class? -- Take the help of EXP bit Results in an LSP called an L-LSP Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Conclusions and Discussion
Metanoia, Inc. Critical Systems Thinking™ Conclusions and Discussion

Conclusions Ethernet poised to be dominant choice in metro networks
Reduces capex and opex for providers Enables new revenue generating services 802.1ad provider bridge with OAM of 802.1ag … … a choice at the edge Two architectures emerging for Ethernet in the metro core Provider Backbone Transport (PBT) IP/MPLS-based L2 VPNs Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Metanoia, Inc. Critical Systems Thinking™ Thank You! Questions?

Glossary AC Attachment Circuit ACL Access Control List AF
Assured Forwarding API Application Programming Interface AS Autonomous System ATM Asynchronous Transfer Mode BA Behavior Aggregate B-DA Backbone Destination Address Backbone Source Address BE Best Effort B-FCS Backbone Frame Check Sequence BGP Border Gateway Protocol CBS Committed Burst Size CE Customer Edge (router) CES Core Ethernet Switch/Bridge CFM CIR Committed Information Rate CO Central Office DA Destination Address DS DiffServ DS DiffServ DSCP DiffServ Code Point EF Expedited Forwarding E-LMI Ethernet-Local Management Interface E-LSP EXP mapped LSP EPL Ethernet Private Line ERO Explicit Route Object E-UNI Ethernet UNI EVC Ethernet Virtual Circuit EVPL Ethernet Virtual Private Line EXP Experimental (EXP bits in MPLS "shim" header) Experimental Bits FCS Frame Check Sequence FEC Forwarding Equivalence Class FIB Forwarding Information Base FR Frame Relay GR Graceful Restart H-QoS Hierarchical Quality-of-Service H-VPLS Hierarchical VPLS IPTV IP Television Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Glossary L2 Layer 2 (Data Link Layer; MAC Layer) L3
Layer 3 (Network or IP Layer) LAN Local Area Network LDP Label Distribution Protocol LER Label Edge Router LIB Label Information Base L-LSP Label inferred LSP LSP Label Switched Path LSR Label Switching Router MAC Medium Access Control MBS Maximum Burst Size MEF Metro Ethernet Forum MEN Metro Ethernet Architecture MPLS Multi-Protocol Label Switching MSTP Multiple Shortest Path Tree MTU Multi-Tenant Unit NG Next Generation NGN Next-Generation Network NNI Network Network Interface OAM Operations, Administration, and Management OSPF Open Shortest Path First P Provider (router) PB Provider Bridging PBB Provider Backbone Bridging PBT Provider Backbone Transport PDH Pleisosynchronous Digital Hierarchy PE Provider Edge (router) PHB Per Hop Behavior PIR Peak Information Rate PSN Packet Switching Network P-VLAN Provider VLAN PW Pseudo-Wire QoS Quality-of-Service RIB Routing Information Base RSTP Rapid Spanning Tree Protocol RSVP-TE Resource Reservation Protocol - Traffic Engineering (RSVP protocol with MPLS traffic engineering extensions) SA Source Address SDH Synchronous Digital Hierarchy SONET Synchronous Optical Network Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Glossary SPT Shortest Path Tree ST Spanning Tree Protocol STP TDM
Time-Division Multiplexing TE Traffic Engineering TM Traffic Management TTL Time to Live UNI User Network Interface VCI Virtual Circuit Identifier VFI Virtual Forwarding Instance VID VLAN Identifier VLAN Virtual LAN VOQ Virtual Output Queue VPI Virtual Path Identifier VPLS Virtual Private LAN Service VPN Virtual Private Network VPWS Virtual Private Wire Service VR Virtual Router VRF Virtual Routing and Forwarding VSI Virtual Switching Instance WFQ Weighted Fair Queuing Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Readings and References (1)
MEF 4: Metro Ethernet Network Architecture Framework Part 1 Generic Framework MEF 6: Metro Ethernet Services Definition Phase 1 MEF 10.1: Metro Ethernet Services Attributes Phase 2 MEF 16: Ethernet Local Management Interface IEEE 802.1d/q WG: “Media Access Control (MAC) Bridges,” IEEE 1998 IEEE 802.1s, “Multiple Spanning Tree,” IEEE 2002 IEEE 802.1ah, “Provider Backbone Bridges,” Work in Progress Documents on the MEF and IEEE and WG web sites Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Readings and References (2)
L. Andersson and E. Rosen, “Framework for Layer 2 Virtual Private Networks (L2VPNs),” RFC 4664, September 2006 K. Kompella and Y. Rekhter, Eds., “Virtual Private LAN Service: Using BGP for Autodiscovery and Signaling,” RFC 4761, January 2007 V. Kompella and M. Lasserre, Eds., “Virtual Private LAN Service: Using Label Distribution Protocol for Signaling,” RFC 4762, January 2007 S. Bryant and P. Pate, Eds. “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” RFC 3985, March 2005 L. Martini et al, Eds., “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP),” RFC 4447, April 2006 Documents on the L2 VPN, PWE3, MPLS, and CCAMP WG’s of the IETF Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Metanoia, Inc. Critical Systems Thinking™ Additional Slides

Label Assignment and Distribution (control component)
Labels Data Labels Data Direction from which labels flow Refers to whether LSR distributes labels on demand or voluntarily Whether LSR waits to hear from its upstream/downstream nbrs. before responding to a request for label(s) Label Retention: Liberal or Conservative Whether LSR keeps labels from a neighbor who is not currently the next hop for a FEC Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

A Word on Reservation Styles
Always chosen by the receiver Two styles apply with RSVP-TE Fixed Filter (FF) Distinct reservation for traffic from each sender Needs unique label per sender Shared Explicit (SE) Common resvn. for traffic from the senders specified by rcvr. May assign unique label/sender Useful for p2p or mp2p LSPs Good afternoon! And welcome to the course on next-generation high-performance switch architectures. Thank you for coming. Over these two days my goal is to explore some details of this subject that will lead to a deeper understanding of the operation of canonical high-speed switch architectures. Before we begin, I’d like to give you a quick overview of the course, and of the sequence in which we’ll cover the material. The material is organized into 6 parts, half of which we’ll cover today. Today, we’ll begin with an overview of some basic switching notions and look at the essential architectural components of switches and cross-connects. We’ll also look at the generic data path processing that occurs within each. We will then look at a taxonomy of switch architectures and switching fabrics. Here we’ll cover the evolution of switch/routers over several generations, and examine the properties and features of different types of switching fabrics. We’ll also review the properties of input and output queueing. Having developed an overall understanding of the architectures of switches and routers, we’ll delve next into tracing the data path through an IP router, a TDM cross-connect, and a hybrid TDM/IP switch, and look at two examples in detail – the Cisco Catalyst switch and the Juniper M Series routers. Starting tomorrow, we will start dissecting each of the three main processing steps in a switch/router--- input processing, scheduling across the switch fabric, and output queueing. We’ll look at methods, algorithms, and techniques for each with a focus on hardware complexity and implementation issues. I have factored in time for discussions, so I hope you’ll ask questions freely at any time during these lectures. This will enable me to adjust my presentations to best help you. It will also make these lectures more interesting for me. If you have additional questions, please feel free to contact me after May 6th. My contact information is on the title slide. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

LDP versus BGP Signaling
Targeted LDP BGP-based Signaling LDP Due to a direct label exchange between peers, PE can send a separate label to each peer (which is what is desired). It is possible to physically segment the network into PE’s that have separate VPLS coverage, so those PE’s that have no VPLS in common do not form any adjacencies. This reduces signaling and # FIBs/PE. BGP The segmentation of PE’s into the VPLS’s they serve is the result of filtering based on the RT attribute, but all of the information does go to every PE. LDP session full mesh b/ween PE’s PE’s exchange labels directly New PE  reconfig. mesh at all PE’s FIB per VPLS per PE RR’s reduce full mesh to 2 sessions/PE Cannot direct label mapping to a specific peer  need label ranges New PE  peering session only w/ RRs Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

L2 VPNS with BGP Autodiscovery + signaling, together via BGP with RTs (per slide 74) PE configured with its VPLS ID (if VPLS) Transmits VPLD ID or identity of attached CE’s to peer PE’s Includes demux value for each BGP NLRI (as a label range) Selection algorithm allows each remote PE to pick correct label for sending traffic to advertising PE BGP NLRI for VPLS BGP NLRI for L2 VPN BGP NLRI either represents a VPLS or represents a CE that is an L2 VPN endpoint. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

BGP-based L2 VPN (VPWS) Since each remote CE must be able to pick a DLCI and a VPN label to communicate with the advertising CE. The VPN label needs to be separate for each remote CE because its traffic must uniquely map to a DLCI on the local PE-CE link. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

BGP-based L2 VPN (VPLS) Now each remote PE must be able to pick a VC LSP label to communicate with the advertising PE. Separate label is needed because you want to know the PE behind which a MAC address lies. Next-Generation Systems & Networks Workshop, 17th July. 2007, Bangalore, India

Metro Ethernet: Understanding Key Underlying Technologies

Similar presentations

Presentation on theme: "Metro Ethernet: Understanding Key Underlying Technologies"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Metro Ethernet: Understanding Key Underlying Technologies

Similar presentations

Presentation on theme: "Metro Ethernet: Understanding Key Underlying Technologies"— Presentation transcript:

Similar presentations

About project

Feedback