Core Networks Evolution

Transcription

1 Core Networks Evolution Prof. Daniel Kofman Telecom Paris - ENST

2 Content Any Service, Any Time, Everywhere, Everyone Towards the triple play and beyond Main trends in Core Networks Architectures From IP over ATM towards MPLS From MPLS towards G-MPLS MAN and WAN, the role of Ethernet interfaces and networking Towards a Unified Control Plane Overlay approach Vs Peer approach Signaling and routing requirements Open Issues Conclusion 2

3 Any service, any time, everywhere Create New Service OK Offered Services Network Operator Contracted Services IP centrex Dist. office Modify Service Backbone Customer Access Network Customer Premises 3

4 Towards IP Multiservice Networks P2P Grid Web Triple play VoIP MmediaoIP Services & Applications over IP SERVICES IP INFRASTRUCTURE IP over any technology 4

5 Historical Perspective : Overlay Networks R3 IP R1 R2 C2 C3 ATM C1 C4 SDH WDM 5

6 The Whole picture Applications IP ATM POS IPO SDH WDM 6

7 Increasing IP Transport Capacity, Option I : IP over ATM R IP R R Customer Premises ATM SDH 7

8 Increasing IP Transport Capacity, Option II : IP over SONET (SDH) R IP R R Customer Premises SDH 8

9 Increasing IP Transport Capacity, Option III : MPLS, Multi-Protocol Label Switching LSR MPLS LSR LSR SDH, other Customer Premises LSR LSR 9

10 MPLS architecture, the FEC concept Partition of the entire set of possible packets into a set of "Forwarding Equivalence Classes (FECs)". FEC: A group of IP packets which are forwarded in the same manner. Classically, a FEC is equivalent to the longest match prefix. Insofar as the forwarding decision is concerned, different packets which get mapped into the same FEC are indistinguishable. 10

11 FEC assignment and subsequent forwarding The label is sent along with the packet. Label is removed at the EGRESS ROUTER, (Label Pop) The packet is assigned to a FEC, and the FEC is encoded with a label at the INGRESS ROUTER, (Label Push) FEC assignment can consider complicated cases, with no impact on the forwarding nodes. MPLS domain Subsequent forwarding is based on the label only. Label Swapping 11

12 FEC assignment and subsequent forwarding (example) /24 FEC X, label 10 i /24 FEC Y, label 20 i /24 FEC Z, label 30 i2 Label Information Base (LIB) Interface Label Interface Interface Label Label Interface Label i0 10i1 i326 26i4 14 i i2 17 i2 16 i3 14 Interface Label Interface Label i1 14 i

13 FEC assignment and subsequent forwarding : Label Switched Path Remark: The packet is assigned to a FEC. The FEC is mapped to a label, which defines a special forwarding treatment The sequence of labels defines a tunnel between the INGRESS and the EGRESS (LSP : Label Switched Path). 13

14 Increase Switching Capacity, Option III : MPLS, Multi-Protocol Label Switching LSR MPLS LSR LSR SDH (??) QoS Managed VPN Traffic Engineering Multicast? Customer Premises 14

15 Traffic Engineering : Need for Automation Traffic engineering : Process of mapping traffic demand (traffic matrix) onto a network topology. Ability to control traffic flows in the network. Optimization vs QoS Protection: Availability, reliability A B A X X X X D X C C B D 15

16 Main trends R3 R1 R2 IP C1 C3 C2 C4 SDH ATM LSR Rapid and Predictable Restoration Standard Time Division Multiplexing IP and ATM integration Label Swapping Paradigm Traffic Engineering MPLS 10Gbps 10Gbps 10Gbps 10Gbps 10Gbps G-MPLS Increasing Capacity Requirements Transparency Sonet / SDH Dynamic Allocation and Control? OCX 10Gbps OCX DWDM Dynamic Allocation and Control? 16

17 Packet + Transport Layers R R IP ATM PACKET LAYER SDH WDM TRANSPORT LAYER 17

18 LAN, MAN and WAN technology convergence First attempt, from WAN to LAN (ATM) Second attempt, from LAN to WAN (Ethernet) What about the AN and the MAN? Metro WDM A-PON, E-PON Ethernet rings and RPR ATM based xdsl architectures Ethernet based xdsl architectures UMTS, from R99 ATM towards R5 and beyond all IP Etc. 18

19 Transport Network: New trends (Automation in Transport Network)

20 From IP over ATM IP ATM 20

21 Towards MPLS over OTN MPLS OTN Required granularity change 21

22 Carrier Network Evolution Phase 0 (Early/Mid 90 s) : Introduction of ATM technology. Mainly based on ATM cross-connects. Phase 1 (Late 90 s) : Introduction of a control plane in ATM networks. ATM Switches supporting PNNI Phase 2 (Late 90 s) : Introduction of UNI to offer customers the ability to set-up connections on demand 22

23 Carrier Network Evolution Phase 0 (Early/Mid 90 s) : Introduction of ATM technology. Mainly based on ATM cross-connects. Phase 1 (Late 90 s) : Introduction of a control plane in ATM networks. ATM Switches supporting PNNI Phase 2 (Late 90 s) : Introduction of UNI to offer customers the ability to set-up connections on demand 23

24 Carrier Network Automation - Phase 1: 1 Soft Permanent Virtual Circuit MANAGEMENT PLANE CONTROL PLANE USER PLANE 24

25 Carrier Network Automation - Phase 1: 1 Soft Permanent Virtual Circuit (2) Benefits of Soft Permanent Connections: Ease of administration (neighbor discovery, link property discovery, ) Decentralized Routing, Control & Management Path protection in arbitrary meshed networks: Large scope of services (1+1, 1:1, m:n, no protection) Adaptive Traffic Engineering (routing, load sharing based on immediate network utilization) Simplified service provisioning process Standardized interfaces (NNI) 25

26 Carrier Network Evolution Phase 0 (Early/Mid 90 s) : Introduction of ATM technology. Mainly based on ATM cross-connects. Phase 1 (Late 90 s) : Introduction of a control plane in ATM networks. ATM Switches supporting PNNI Phase 2 (Late 90 s) : Introduction of UNI to offer customers the ability to set-up connections on demand Bandwidth on demand Example of usage: Grid 26

27 ASON: Control Plane for the Optical Network

28 Carrier Network Evolution ASON: Goals of the architecture Main Benefits for a control plane for OTNs: More flexible O&M Soft-permanent connections Re-configuration of existing connections Restoration in meshed networks Reduced O&M Cost Reduced provisioning time Connections on demand (bandwidth on demand) if UNI is offered Main Requirements: Signaling protocol adapted to OTN Routing Protocol adapted to OTN Other (local management interface, etc.) Proposals: Several proposals from different standardization bodies: OIF, ITU, AF, IETF, 28

29 Layer Integration : : CCAMP Both layers of the overlay have a control & management plane Why not building a Common Control and Management Plane In IP/ATM overlay, some works done (PAR et I-PNNI), but met little success. Existing IP and ATM control technologies (not starting from scratch) Bottom-up approach (ATM routing and addressing for IP) Integration of BOTH User and Control Plane was preferred (MPLS). Allows to set-up connections (i.e. LSP) in heterogeneous environment (ATM/IP) In MPLS/OTN Overlay, Integrating User plane does not make practical sense in the short term Different switching paradigms (Packet/Time/Lambda/Fiber Switching) MPLS signaling and routing offers all required features and extension capabilities needed for controlling OTNs. 29

30 The Overlay model Layers are independent in term of Routing For instance: IP routers don t see physical topology and are connected by SDH channels Physical channels are (semi-)permanent (Static Overlay) or switched (Dynamic Overlay). P T 30

31 The Peer model Equipments of both layers are peers w.r.t. routing and signaling. For instance, Routers see SDH topology and can open ondemand channels by signaling. In this example, SDH switches don t necessarily see IP topology but transport IP routing information as opaque information. IP 31

32 Standards, Standardization bodies Proposed Architectures/Protocols ITU-T (ASON: Automatic Switched Optical Network) IETF (Common Control and Management Plane WG) OIF UNI Choice of Signaling Procedures & Protocols RSVP-TE (IETF) and derivatives (OIF, ITU-T for ASON) CR-LDP (IETF) and derivatives (OIF, ITU-T for ASON) PNNI extensions (AF) for ITU-T ASON 32

33 Generalizing MPLS

34 Generalizing MPLS for ASON MPLS is a good candidate for controlling ASON: Extensible Signaling & Routing protocols Support for TE Support of Hierarchy Link betwee n LSR1 and LSR2 may be virtual LSR1 LSR1 LSR2 LSR3 LSRa LSRc LSR2... LSRb Fiber (Fiber Switching: FSC) Wavelength (Lambda Switching: LSC) Time Slot (TDM: TDM) Layer 2 (Layer 2 Switching: L2SC) IP/MPLS (Packet Switching: PSC 1,2,3,4, ) 34

35 GMPLS: Overview MPLS paradigm and Limitation : Paradigm: data forwarding based on a label. Limitation: label inferred from packet (explicit label) G-MPLS Objectives : A Single unified control plane for all switching paradigms Integration of different switching paradigms Classification of Interfaces (Packet, L2, Time, Wavelength, Waveband, Space). Notion of GMPLS Hierarchy. 35

36 G-MPLS : Main Open Issues and Challenges

37 From MPLS towards G-MPLSG MPLS-TE provides a suitable architecture Nevertheless, new constraints arise with heterogeneous switching capabilities : Differentiate switching capabilities and associate label definitions Out-of-band signaling Manipulation of discrete bandwidth Light-path continuity Maximum number of transparent optical hops Large number of sub-interfaces in D-WDM Larger number of equipments participation in routing So extensions are currently under development at IETF For routing protocols For signaling protocols For local management protocol 37

38 GMPLS: Opportunities and Threats

39 GMPLS: Opportunities Intense activity on a generic Link Management Protocol at IETF CCAMP (or OIF/ITU-T equivalent protocols): Management Task Automation is clearly necessary (even if no signaling and routing is deployed). Error prone Human Configuration Link property discovery, correlation Neighbor discovery, Service Discovery Requests for bandwidth on demand services SDH/WDM granularity no longer a problem given today bandwidth needs Hitless bandwidth modification, Choice of deployment/service provisioning models Static Overlay Dynamic Overlay Partial/Full Peer Model Centralized/Distributed Routing and Provisioning 39

40 GMPLS: Threats Carriers are reluctant to deploy distributed routing/resource provisioning architectures for the transport network Feel like loosing control on network Strong expertise (or even culture!) in Centralized Management systems Network dimensioning/traffic Engineering tools for G-MPLS still to be developed (research community has a role to play here!) Need for robust, stable platforms Short term: Low investments of manufacturers 40

41 Thank you for your attention