Metanoia is a technology consultancy that provides expertise in telecommunications networks. The document outlines Metanoia's background and expertise. It then summarizes a workshop on Metro Ethernet technologies that Metanoia will present. The workshop will cover legacy networks, Metro Ethernet Forum standards, Ethernet over legacy networks, native Ethernet services, and technologies like MPLS, VPNs, and resilience.
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.
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.)
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 …
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.
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.
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.
Learning and forwarding based on MAC address, and switching of packets between tunnels based on MAC addresses, plus interworking with IEEE 802.1 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.
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.
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.
This example shows how a full-mesh of PWs and tunnels, together with split-horizon forwarding provides loop freedom.
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.
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.
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 6 th . My contact information is on the title slide.
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
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.
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.
-- 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>
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
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 6 th . My contact information is on the title slide.
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.
BGP NLRI either represents a VPLS or represents a CE that is an L2 VPN endpoint.
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.
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.