future internet chapter 3: (virtual) circuitswitching or: a...

Computer Networks GroupUniversität Paderborn

Future Internet Chapter 3: (Virtual) circuit switchingor: a tale from the past

Holger Karl

SS 19, v 1.3 FI - Ch 3: (Virtual) circuit switching 2

Overview

• (Virtual) circuit vs. packet switching• The old: ATM • The current: MPLS


The thorns of IP

• What made IP forwarding hard?

• Packets of different lengths

• Complex destination address -> outgoing port lookup in forwarding

plane

• Very hard to impossible to provide any kind of guarantees

• No central view on network

• Historically, we did not always build networks like that

• … nor do we do that today

• A look at the past: Asynchronous Transfer Mode (ATM)

• Started in the 1960s, had its big day in the 1990s

• .. and at the present: Multi-protocol label switching (MPLS)


ATM – Basic concepts

• Virtual circuits (VC)• Switches know how to handle data arriving in a VC• VCs have to be setup before data can travel along it • VCs have explicit names – Virtual Circuit Identifiers (VCI)• Packets contain this VCI in header, not a destination address

• Can be much smaller than a full destination address

• Forwarding deterministic based on VCIs, all data on one VC follows same route

• Results in separated control and data handling• Operating at different time scales; eases HW/SW separation

• VCs can be setup per call/connection or permanently



• Fixed-size packets – or cells • Makes buffer management, switching fabric, line scheduling

MUCH easier • But causes segmentation/reassembly overhead

• Small cells• Necessitates small addressing for acceptable overhead • Historical decisions; was meant for voice traffic (follow-up to PSTN

STM network) • Size: industry conflict between

• Small cells ! low delay ! no echo cancellation needed vs. • Big country ! needs echo cancellation anyway ! wants small

overhead • Ended up as compromise: 48 bytes payload, 5 bytes header



• Statistical multiplexing• Deal with outgoing link data rate < sum of incoming data rates • Multiplexing gain = sum of incoming / outgoing rate

• Integrated services • Provide support for different service types (voice, data, …)

explicitly


Uniqueness of VCIs

• Simple approach: all VCs sharing at least a single link must have different VCIs • Scaling problems

• Better: VCI swapping • Switches can rewrite VCI identifiers in incoming cells, based on

incoming port: (Incoming port, Incoming VCI) ! (Outgoing port, Outgoing VCI)

• These rules are collected in a switch’s translation table • Entails per-VC state in each switch!

• Switching becomes a simple lookup operation in translation table!


Setting up VCs

• Option 1: Let each switch locally do routing on the call setup cells • Handle translation tables locally as well

• Option 2: “Global” view ?


ATM state of affairs

• Currently, no longer a relevant system for research or new

deployment

• … but still sits in some backdoor closets somewhere

• Largely replaced by its successor, MPLS

• See IETF RFC 3031 plus follow-up RFCs

https://tools.ietf.org/html/rfc3031


From ATM to MPLS

• ATM turned out to be inflexible, evolved towards MPLS

• Main similarities • MPLS is a label-switched protocol, just like ATM uses the virtual

circuit identifiers (a terminology difference only) • MPLS has a similar translation table for its labels • Forwarding still stays a simple table lookup

• Main differences • MPLS can support varying payload size • MPLS can carry (“tunnel”) arbitrary network layer protocols; MPLS

prepends a so-called shim header • Shim: Label, QoS, stack bit, time to live

• VC setup works differently


MPLS control vs. data

• Like ATM, MPLS maintains a clear and strict separation of data and control plane • Data plane: Only forwarding, based only on labels, very simple

• Much simpler than IP: no longest prefix matching, no routing algorithms at all in the switch

• Control plane: • Protocols to determine reachability information (aka routing) or to

import it from other networks (e.g., talk to IP BGP routers to understand which network prefixes are attached where)

• Protocols to distribute labels (Label distribution protocols, LDP) • For discovered network prefixes, distribute labels to relevant routers • Proactively or on-demand • Various options, e.g., RSVP, MP-BGP, …

• Traffic engineering functionality


MPLS translation table – power over ATM

• Translation tables under MPLS much more powerful

• ATM: only action was to replace a VCI by another and forward

• MPLS: Actions by a label-switched router (LSR) • Replace label by another and forward

• Insert another shim header! (Push a label onto a label stack)

• Remove a shim header and look at the resulting packet

• Label stack allows nesting of virtual circuits inside each other

• Great tool for traffic engineering

• Once last shim header is removed, pass contained packet to whatever network protocol, e.g., IP

An MPLS label

https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching


Switching table in an MPLS LSR

• What’s hence needed in an MPLS LSR switching table? • What are differences to an Ethernet switch?

• Ethernet switching table columns: • Destination MAC address• Outgoing port

• MPLS switching table columns - Next Hop Label Forwarding Entry (NHLFE)• Incoming label • Incoming port • Outgoing label• Outgoing port • Optional: Operations on label stack (push, pop)


Why?


Where do MPLS labels come from? • Typical setup: an MPLS network interconnects various other networks

• E.g., IP networks interconnected by MPLS

• At some point, non-MPLS packet arrives at the first MPLS router • So called label edge router (LER)

• LER can analyse packet and decide its forwarding equivalence class(FEC)

• FEC: Set of packets to be forwarded in the same fashion (same path)• Decision based on destination IP, source IP, QoS, time of day, load situation

of network, non-local information, … • Information that is not necessarily available to an IP router inside a network!

• For each FEC, there is a label-switched path (LSP) with according label

• LER inserts shim header with this label and starts switching the packet • Typically, multiple FECs on same LSP


Example: Traffic engineering with MPLS


MPLS’ hidden jewel (?): Path Computation Element • Determining routes when setting up a label: so far, distributed

process similar to a packet router assumed• Actually, MPLS reuses IP routing (not forwarding!) protocols like

OSPF to distribute topology information (or better, OSPF-TE with traffic engineering extensions)

• Typically: Label Edge Router decides on path

• Alternative proposal: Decide on paths in a centralized way!• Introduce a central instance where routing decisions are taken,

entries for translation tables are then redistributed • So-called Path Computation Element (PCE) • Presentation here based on RFC 4655

• Note: This makes a lot more sense in a “virtual circuit” model rather than a packet forwarding model • Unlike packets, decisions on path setup only happens rarely – can be

done centrally, simplifies network management a lot


Why centralized path computations?

• More complex algorithms could be used • E.g., shared backup paths for paths that do not interact with each

other

• Bundles of requests can be considered and optimized jointly• E.g.: Setup a VLAN between multiple sites; only relevant if all of

paths obtain certain quality • Limited visibility in distributed solutions

• E.g., multi-domain, multi-carrier, multi-layer • Dealing with legacy equipment without control functionality

• In particular, optical nodes • Management simplified in general; one place to put control

functions


Path Computation Element

• To quote RFC 4655: • A Path Computation Element (PCE) is an entity that is capable of

computing a network path or route based on a network graph, and of applying computational constraints during the computation.

• The PCE entity is an application that can be located within a network node or component, on an out-of-network server, etc.

• For example, a PCE would be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request.


Path Computation Element

• Terminology: • TED: Traffic Engineering Database, contains topology and

resource information of given network domain. Derived from routing protocols like IGP (at slow time scales)

• TE LSP: Traffic Engineering MPLS Label Switched Path • Domain: Collection of network elements with common sphere of

management, e.g., an AS • NMS: Network Management System


PCE Architecture

• PCE receives/answers requests via the Path Computation Element communication protocol (PCEP)

• PCE talks to Path Computation Clients (PCC) and NMS

• Main operation sequence: • PCC requests path towards given destination

• Typically, the LER is the PCC• Request can contain optional parameters (bandwidth, excluded

objects, … )• PCE computes it, returns path

• Path can contain strict nodes or loose nodes (loose: additional nodes maybe inserted into path before it, see RSVP-TE, RFC 3209)

• PCC uses signalling protocol to request corresponding path

From [3]


Single or multiple PCEs

From [3]


Example use case: Multi-domain Path Computation

From [3]


From MPLS to GMPLS

• MPLS hugely successful • Got extended in multiple directions – Generalized MPLS

• Additional packet switching technologies on top (not just IP, as in MPLS)

• Additional layer 2 technologies • Interesting example: Doing label switching directly on optical fibre

– GMP¸S• Using the basic circuit setup infrastructure of MPLS, but doing the

actual switching not by looking at labels, but rather by optical switches directly switching on wavelengths (¸)

• Generalized label can here represent an entire fibre, a wavelength in a fibre, or timeslots in such a wavelength (building a “virtual channel”)


Summary

• Virtual circuit switching is still a powerful technique • Determining fate of data at the edge turns out to be a big

lever indeed • The idea to have a global view of the network is much

easier in circuit-switched networks than in packet-switched networks


References

1. Material by Cisco and Juniper, various, on their websites2. A. Farrel, J.-P. Vasseur, J. Ash, A Path Computation

Element (PCE)-Based Architecture, Aug. 2006, RFC 4655.

3. F. Paolucci, F. Cugini, A. Giorgetti, N. Sambo, and P. Castoldi, “A Survey on the Path Computation Element (PCE) Architecture,” IEEE Communications Surveys & Tutorials, pp. 1–23, 2013.

future internet chapter 3: (virtual) circuitswitching or: a...

Documents