1 / 32

Lecture 2. Core network evolution

Lecture 2. Core network evolution. D. Moltchanov , TUT, Spring 2010. D. Moltchanov, TUT, Spring 2008. Outline. What drives network evolution Evolution of L3 network Evolution of L1/L2 networks Vendors’ view Operator’s view Next lectures. What drives network evolution.

shirleyo
Download Presentation

Lecture 2. Core network evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 2. Core network evolution D. Moltchanov, TUT, Spring 2010 D. Moltchanov, TUT, Spring 2008

  2. Outline • What drives network evolution • Evolution of L3 network • Evolution of L1/L2 networks • Vendors’ view • Operator’s view • Next lectures

  3. What drives network evolution • Money: Make more revenue • How: better networks – more users – more revenue • How: reduce CAPEX and OPEX • Converge to single multi-service network • How: the only choice - everything over IP • Several single service networks: OPEX ~ 70% CAPEX • Optimize network resources and capabilities • How: traffic engineering • Enhance reliability/survivability • How: traffic engineering • Enhance management performance • How: simple and well-defined methodologies • Enable cost-effective provisioning of new services • How: multi-service network

  4. Beginning of 90s: IP over Tx/Ex • Beginning on 90th: • Transport network: E1 (T1), E3 (T3) • Only few transport nodes to configure and control • Manual configuration is feasible • Routers’ performance is unstable • IGPs metrics are sufficient to control the load • Traffic chooses the link with the least metric • Path via C is not used

  5. Beginning of 90s: problems • Problems with IP networks in the middle of 90: • Insufficient throughput of transport network • Topology of the transport network gets complicated! • Manual configuration is no longer feasible! • Unstable and insufficient performance of routers • We needed a breakthrough in hardware and software! • Using IGP’s metric is not the best way to control traffic • Topology of the transport network gets complicated! • Routing does not depend on the traffic • IGP: only topology is taken into account • Analysis IP header is too slow for high speed networking • Basically, we needed: • High speed transport network • Fast and stable forwarding at IP • Traffic control features

  6. Middle of 90s: IPoverATM • Addressing the needs: • SDH/SONET • High-speed low layer transport • ATM • Forwarding: fast and reliable • VC/VP switching • IP over ATM • Virtual(!) topology for traffic control • Advantages of IP/ATM • High-speed technology • Traffic control • Usage statistics for each VC, etc. • SDH/ATM/IP: logical networks (overlays)

  7. Middle of 90s: Logical networks • Physical network • Logical IP network

  8. Middle of 90s: +/- of IPoverATM: • Operating ATM network is (relatively) simple • Software estimates the path based on • Links load and type of traffic on links • Virtual network • Primary and secondary paths • Automatic switch configuration • Shortcomings of IP/ATM • Problems with topology • Physical network is not logical • Huge overhead (control information) • ATM: ~20% are headers • STM-16(2.4Gbps): 498Mbps, STM-64 (9.9Gbps): 1.99Gbps – headers • Do not forget IP/TCP headers! • High speeds of ATM are still not fully used by IP • Performance of IP equipment is still limited

  9. End of 90s • End of 90s: • Breakthrough in routers: high-speed routers • High-speed hardware • New advanced software • Rise of giant vendors: Cisco, Nortel, Alcatel, Ericsson, Nokia • Result: stable performance of IP routers • There were two ways to the future: • Continue with IP over ATM • Huge overhead (only ATM gives ~20%) • Propose new high-speed technology • Low overhead! • Compatible with IP! • Automatic traffic control: • path selection, fast reroute, etc. • It should be a compromise between VC and routing

  10. End of 90s:Cisco’s tag switching • The main aim: • Speed up the packet treatment in routers • Allow automatic traffic control • Tag switching:Cisco Systems • Proprietary solution • Tag is added to each packet • Tag info: next hop • Standards:IETF drafts • ‘Tag Distribution Protocol’ • ‘Tag Switching Architecture Overview’ • ‘Use of Flow Label for Tag Switching’ • ‘Use of Tag Switching With ATM’ • ‘Tag Switching: Tag Stack Encoding’

  11. End of 90s:tag switching • Two basic components • Forwarding • Packet forwarding to the next hop • Basis:tag info (value) • Control • Getting and distributing info regarding the next hops • How tag is carried out: • Separate 2.5 level header • Frame header at the data-link layer • For example,ATM • Packet header at the network layer • For example, IPv6, “Flow label” field

  12. End of 90s:tag switching • Forwarding: • Each node maintains tag information database • Tag Information Base (TIB): forwarding table • Correspondence: {incoming tag, interface} – {outgoing tag, interface} • When a packet with tag is received • Node looks for entry inTIB • If exists: tag is changed, packet is forwarded to the outgoing interface • Advantages of tag switching: • High speed due to • Strict correspondence algorithm for forwarding • Short and fixed length tag • Forwarding is unified • One-to-one:one outgoing tag • One-to-many:a number of outgoing tags • Traffic engineering is very easy to do • Control is well isolated from forwarding

  13. Beginning of 2000s: MPLS • What is that? • Very similar to ATM • Successor of tag switching • Multi-protocol label switching • Actually: fast packet switching technology • Operates between layers 2 and 3 • Much faster than IP • MPLS combines advantages of: • АТМ:switching • IP:routing

  14. Beginning of 2000s:MPLS philosophy • Traditional routing • IP packet is routed hop-by-hop • Hop-by-hop routing • Decision regarding the next hop is made independently • IP header is analyzed in each router • IP header contains many fields • HOP-BY-HOP! • MPLS approach • IP header is analyzed only once: source routing • At the entrance to MPLS domain • Packet is associated with a certain flow • Flow is identified with a label • Only label is then analyzed in the core of a domain • SOURCE ROUTING!

  15. Beginning of 2000s:traffic engineering • Traditional traffic control • Chose a shortest path • Avoid node/link failures: possible • Avoid overloaded paths: not possible • MPLS traffic control • Creating virtual switched paths • LSP, Label-Switched Path • Analog to virtual circuitsinATM • We control how traffic crosses the network • Packet on a switched path • No delivery guarantees • Priorities exist • Intermediate nodes use label value to switch • Reliability: primary and secondary path

  16. Beginning of 2000s: +/- of MPLS • Fast forwarding • Label is faster to analyze than several fields • Low overhead • Header overhead is really small (compare to ATM) • Traffic engineering • Very important feature making MPLS widespread • Single, integrated network • Can still run above ATM/FR etc. • Developed specifically for IP

  17. Up to 2005: GMPLS • Generalized MPLS • Logical evolution and generalizationof MPLS • Allows to switch at 1, 2, 3 layers • Setting up LSP between identical bearers • GMPLS standardization • IETF RFC 3471: labels encoding • Usage forSONET/SDT • draft-ietf-ccamp-gmpls-sonet-sdh-08.txt • LSP management protocol • draft-ietf-ccamp-lmp-10.txt • Extensions ofOSPFforGMPLS support • draft-ietf-ccamp-ospf-gmpls-extensions-04.txt • Routing requirements forGMPLS support • draft-ietf-ccamp-gmpls-routing-09.txt • RSVP-TE extensions for optical networks • draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt

  18. Up to 2005: basic idea of GMPLS • Basic idea ofMPLS • Provide faster forwarding compared to plain IP • Provide better traffic engineering compared to OSPF or IS-IS • Basic idea of GMPLS • Create LSP at any layer • Flexibility of overlays construction • No difference whether it is • IPpacket • TDM SDH/SONET frame • DWDM wavelength • Each GMPLS node • Support label distribution • Set up LSP

  19. Up to 2005: GMPLS capabilities • Four types ofLSP • Optically switched • Fiber-switched capable (FSC) • Switching fibers • Lambda switched • Lambda-switched capable (LSC) • Switching wavelengths • Adapted forDWDM (Dense Wavelength Division Multiplexing) • TDM switched • TDM-switched capable (TSC) • Switching for SDH/SONET • Packet switched • Packet-switched capable • Switching for IP routers (MPLS), ATM switches, etc. • More flexiblecompared to MPLS • Contains next hop identifier • Fiber port, TDM slot, DWDMwavelength,…

  20. Physical network evolution • Up to 1990 • Tx/Ex networks • T1/E1, T3/E3 are mostly used • Relatively slow technologies (E1: 2Mbps, E3: 34 Mbps) • There was no need for more than 100Mbps • 1990 – 2000 • SDH/SONET • Very high speed up to several Gbps • 2000 - now • (D)WDM • Up to few Tbps • Nowadays: DWDM

  21. Vendors nowadays • IP/MPLS solutions • Why? • Still in agreement with ‘everything over IP’ • Traffic engineering is crucial • Fast forwarding is crucial • Software update makes MPLS switch • IP-based solutions can still be used • Experience of IP networks • Operators choice! • Who provides equipment • Cisco • Juniper • Riverstone • …

  22. Operators nowadays • IP/MPLS solutions • Remember, operators are much more realistic! • What are operators’ visions • Verizon • DiffServ/MPLS • Level3 • DiffServ/MPLS • Very strong QoS support • British Telecom • Overprovisioning/DiffServ/MPLS • Proprietary weak and simple TE features • Telecom Italia • Overprovisioning/DiffServ/MPLS • Strong QoS support

  23. Evolution strategies: Verizon • Single IP/MPLS core network • RSVP-TE is used for label distribution • IS-IS-TE and BGP as intra- and inter-domain routing • Traffic engineering • Load balancing + MPLS fast reroute for reliability • MPLS-based VPNs • Especially, VPLS • BGP/MPLS VPN and VPWS-martini

  24. Evolution strategies: Verizon’s bearers • Transmission network • Completely replace copper wire by fiber optics • Use DWDM • Evolve SONET further • Fiber to home • Logical network • MPLS+DiffServ • QoS across multiple domains • Edge equipment • Traffic control, e.g. monitoring, labeling, COS mapping • AQM should be used e.g. RED, RIO

  25. Evolution strategies: Level3 • IP MPLS • MPLS-based VPNs • VPLS • BGP/MPLS (RFC 2547) • End-to-end QoS • Does not recommend overprovisioning in MPLS backbone • Service differentiation of DiffServ • Bandwidth reservation of MPLS • QoS/COS support even in backbone • Other operators believe in QoS only in edge networks • Level3’s solution: DiffServ/MPLS

  26. Evolution strategies: BT • Simplicity is the way to the future • Multi-service access nodes at edges • Support softswitches for narrowband voice • SIP-based IMS for broadband multimedia • By 2007 50% PSTN exchanges have been replaced • Core network: IP/MPLS • Classic TE is too complex • Develop its own proprietary simple TE • QoS in access network: fiber networks, overprovisioning • Transmission backbone: DWDM

  27. Evolution strategies: Telecom Italia • IP/MPLS-based optical backbone backbone • Core network • MPLS-TE with OSPF-TE for bandwidth guarantees • DiffServ for service differentiation • MPLS-based VPNs • Access network • Fiber to home • xDSL for copper wire access • Transmission backbone: DWDM

  28. Evolution strategies: summary • Everything over IP • Most of operators agree on that • Build backbone using IP-MPLS-DWDM • Use MPLS-based VPNs • Build access using xDSL and BPON • Deploy QoS in core using • DiffServ for service differentiation • MPLS for bandwidth reservation • Overprovision to some degree • Introduce new services, e.g. IPTV • We consider everything related to IP/MPLS/DiffServ/VPN

  29. Evolution strategies: QoS? • Do we really need special mechanisms? • Resource reservation? • Service differentiation? • Is traffic engineering enough? Some think so • Put some routers • Balance load • Upgrade PHY network • Killer application nowadays: P2P • 60-70% of all traffic (BitTorrent ~20%) and continue to grow • P2P streaming is still in his early stages and evolves very fast • Overlays that do not care about underlying network • Non-optimized solutions at all in terms of resource usage • “Overprovisioned” backbones are becoming bottlenecks… • We will always have enough traffic to fill the network…

  30. Is providing QoS fair to end users? • Prior to year ~2000 • No doubts about that • I pay, you guarantee… • Nowadays some new trends • Network neutrality initiative • What? Internet traffic should be treated equally • Why? Operators may try to block content, degrade performance • Advocates: network is simply a bearer for services • Critics: congestions, searching for a problem • A lot of non-related stuff… • More at http://en.wikipedia.org/wiki/Network_neutrality

  31. Summary • Driving force: more revenue… • Support more users • Decrease CAPEX and OPEX • Enable higher access rates • Single multi-service network • Enhance disaster/failure recovery • Optimize resources • Everything is IP based • Main directions • Everything for IP • Higher PHY rates • Simple but robust control • Reduce CAPEX when enabling a new services

  32. What we are going to consider • Lecture 3: Basics of MPLS • Label encoding, LSR operations, LSPs • Label distribution protocols (LDP) • Lecture 4: Traffic engineering in MPLS • CR-LDP, RSVP-TE • Bandwidth reservation, interception, fast-reroute, etc. • Lecture 5: DiffServ/MPLS • Problems of DiffServ and MPLS • DiffServ-aware MPLS TE • Lecture 6: L2 MPLS VPN • VPWS, VPLS, HVPLS, IPLS • Modes, signaling, operation in details • Lecture 7: L3 MPLS VPN: BGP/MPLS (2547 VPN) • Modes, signaling, operation in details • Configuration examples

More Related