Post on 14-Apr-2018
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 1/41
Core Networks EvolutionCore Networks Evolution
Prof. Daniel Kofmandaniel.kofman@enst.fr
Telecom Paris - ENST
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 2/41
2
ContentContent
• 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
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 3/41
3
Any service, any time, everywhere Any service, any time, everywhere
Network Operator
Customer
Premises
Access Network
Offered Services
Create New Service
OK
ContractedServices Modify Service
Backbone
IP centrex
Dist. office
Customer
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 4/41
4
Towards IP Multiservice NetworksTowards IP Multiservice Networks
INFRASTRUCTURE
IP over any technology
SERVICES
VoIP
MmediaoIPWeb
P2P
Services & Applications
over IP
IP
Grid
Triple
play
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 5/41
5
Historical Perspective : Overlay NetworksHistorical Perspective : Overlay Networks
WDM
SDH
R2
R3
R1
IP
ATMC1
C2
C3
C4
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 6/41
6
WDMWDM
ATM ATM
SDHSDH
IPIP
Applications Applications
The Whole pictureThe Whole picture
P O S
I P O
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 7/41
7
Increasing IP Transport Capacity, Option I :Increasing IP Transport Capacity, Option I :
IP over ATMIP over ATM
Customer
Premises
R
R
R
IP
ATM
SDH
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 8/41
8
Increasing IP Transport Capacity, Option II :Increasing IP Transport Capacity, Option II :
IP over SONET (SDH)IP over SONET (SDH)
Customer
Premises
R
R
R
IP
SDH
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 9/41
9
Increasing IP Transport Capacity, Option III :Increasing IP Transport Capacity, Option III :
MPLS, MultiMPLS, Multi--Protocol Label SwitchingProtocol Label Switching
Customer
Premises
LSR
LSR
LSR
MPLS
SDH,
other
...
1 8 8 0
...
18 54
LSR LSR
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 10/41
10
MPLS architecture, the FEC conceptMPLS 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 packetswhich get mapped into the same FEC are indistinguishable.
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 11/41
11
FEC assignment and subsequent forwardingFEC assignment and subsequent forwarding
The packet is assigned to aFEC, and the FEC is encodedwith a “label” at the I NGRESS
ROUTER,
(Label Push)
FEC assignment can considercomplicated cases, with noimpact on the forwardingnodes.
The label is sentalong with thepacket.
Subsequentforwarding isbased on thelabel only.
“Label
Swapp ing”
Label isremoved atthe EGRESS
ROUTER,
(Label Pop)
MPLS domain
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 12/41
12
FEC assignment and subsequent forwardingFEC assignment and subsequent forwarding
(example)(example)
137.194.1.0/24 FEC X, label 10 i1
137.194.2.0/24 FEC Y, label 20 i2
137.194.3.0/24 FEC Z, label 30 i2
Label Information Base (LIB)
Interface Label Interface Label
i0 10 i3 26
i1 14 i2 17
i2 16 i3 14
Interface Label Interface Label
i1 26 i4 14
...
Interface Label Interface Label
i1 14 i3 --
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 13/41
13
FEC assignment and subsequent forwarding :FEC assignment and subsequent forwarding :
Label Switched PathLabel Switched Path
Remark:
The packet is assigned to a FEC.
The FEC is mapped to a label, whichdefines a special forwarding treatment
The sequence of labels defines a “tunnel” between the INGRESS and theEGRESS (LSP : Label Switched Path).
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 14/41
14
Increase Switching Capacity, Option III :Increase Switching Capacity, Option III :
MPLS, MultiMPLS, Multi--Protocol Label SwitchingProtocol Label Switching
Customer
Premises
LSR
LSR
LSR
MPLS
SDH(??)
• QoS
• Managed VPN
• Traffic Engineering• Multicast ?
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 15/41
15
Traffic Engineering : Need for AutomationTraffic Engineering : Need for Automation
X X
X X
X X
X X
B
C
D
X X
A
A
B D
CTraffic engineering :• Process of
mapping trafficdemand (trafficmatrix) onto anetwork topology.• Ability to controltraffic flows in the
network.• Optimization vsQoS• Protection: Availability,reliability
Traffic engineering :• Process of
mapping trafficdemand (trafficmatrix) onto anetwork topology.• Ability to controltraffic flows in the
network.• Optimization vsQoS• Protection: Availability,reliability
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 16/41
16
GG--MPLSMPLS
Main trendsMain trends
IP and ATM integration
Label Swapping ParadigmTraffic Engineering
MPLS
10Gbps
10Gbps
OCX OCX
10Gbps
10Gbps10Gbps
10Gbps
IncreasingCapacity Requirements
DWDMDynamic Allocation and Control?
ATM
C1
C2
C3
C4
R2
R3
R1
IP
ATM
C1
C2
C3
C4
R2
R3
R1
IP
LSR
SDHSDH
Rapid and Predictable RestorationStandard Time Division Multiplexing
Transparency
Sonet / SDHDynamic Allocation and Control?
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 17/41
17
Packet + Transport LayersPacket + Transport Layers
WDM
SDH
R
R
IP
ATM
TRANSPORT LAYER
PACKET LAYER
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 18/41
18
LAN, MAN and WAN technology convergenceLAN, 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.
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 19/41
Transport Network:Transport Network:
New trendsNew trends
(Automation in Transport Network)(Automation in Transport Network)
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 20/41
20
From IP over ATMFrom IP over ATM ……
IPIP
ATM ATM
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 21/41
21
…… Towards MPLS over OTNTowards MPLS over OTN
MPLSMPLS
OTNOTN
Required granularity change
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 22/41
22
Carrier Network EvolutionCarrier Network Evolution
• Phase 0 (Early/Mid 90’s) : Introduction of ATMtechnology. Mainly based on ATM cross-connects.
• Phase 1 (Late 90’s) : Introduction of a control planein ATM networks. ATM Switches supporting PNNI
• Phase 2 (Late 90’s) : Introduction of UNI to offercustomers the ability to set-up connections on
demand
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 23/41
23
Carrier Network EvolutionCarrier Network Evolution
• Phase 0 (Early/Mid 90’s) : Introduction of ATMtechnology. Mainly based on ATM cross-connects.
• Phase 1 (Late 90’s) : Introduction of a control planein ATM networks. ATM Switches supporting PNNI
• Phase 2 (Late 90’s) : Introduction of UNI to offercustomers the ability to set-up connections on
demand
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 24/41
24
Carrier Network AutomationCarrier Network Automation -- Phase 1Phase 1::Soft Permanent Virtual CircuitSoft Permanent Virtual Circuit
MANAGEMENT PLANE
USER PLANE
CONTROL PLANE
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 25/41
25
Carrier Network AutomationCarrier Network Automation -- Phase 1Phase 1::
Soft Permanent Virtual CircuitSoft Permanent Virtual Circuit (2)(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 onimmediate network utilization)
– Simplified service provisioning process
– Standardized interfaces (NNI)
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 26/41
26
Carrier Network EvolutionCarrier Network Evolution
• Phase 0 (Early/Mid 90’s) : Introduction of ATMtechnology. Mainly based on ATM cross-connects.
• Phase 1 (Late 90’s) : Introduction of a control planein ATM networks. ATM Switches supporting PNNI
• Phase 2 (Late 90’s) : Introduction of UNI to offercustomers the ability to set-up connections ondemand – “Bandwidth on demand”
– Example of usage: Grid
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 27/41
ASON: Control Plane for the Optical Network ASON: Control Plane for the Optical Network
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 28/41
28
Carrier Network EvolutionCarrier Network Evolution – –
ASON: Goals of the architecture 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,…
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 29/41
29
“ “Layer IntegrationLayer Integration” ” : CCAMP: 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 metlittle success.
– Existing IP and ATM control technologies (not starting fromscratch)
– 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 andextension capabilities needed for controlling OTNs.
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 30/41
30
The Overlay modelThe Overlay model
– Layers are independent in term of Routing
– For instance:
• IP routers don’t see physical topology and are connected by SDHchannels
• Physical channels are (semi-)permanent (Static Overlay) or switched(Dynamic Overlay).
TT
PP
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 31/41
31
The Peer modelThe Peer model
– Equipments of both layers are “peers” w.r.t. routing andsignaling.
• For instance, Routers “see” SDH topology and can open on-demand channels by signaling.
• In this example, SDH switches don’t necessarily “see” IP
topology but transport IP routing information as opaqueinformation.
IPIP
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 32/41
32
Standards, Standardization bodiesStandards, 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
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 33/41
Generalizing MPLSGeneralizing MPLS
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 34/41
34
GeneralizingGeneralizing MPLS for ASONMPLS for ASON
LSR1
LSR2
LSR3
Link between LSR1
andLSR2
may bevirtual
LSR1
LSR2LSRa
LSRb
LSRc
• MPLS is a good candidate forcontrolling ASON:
– Extensible Signaling & Routingprotocols
– Support for TE
– Support of Hierarchy
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,…)
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 35/41
35
GMPLS: OverviewGMPLS: 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.
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 36/41
GG--MPLS :MPLS :
Main Open Issues and ChallengesMain Open Issues and Challenges
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 37/41
37
From MPLS towards GFrom MPLS towards G--MPLSMPLS
• MPLS-TE provides a suitable architecture
• Nevertheless, new constraints arise with heterogeneousswitching 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
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 38/41
GMPLS:GMPLS:
Opportunities and ThreatsOpportunities and Threats
GMPLS O i iGMPLS O t iti
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 39/41
39
GMPLS: OpportunitiesGMPLS: Opportunities
• Intense activity on a generic Link Management
Protocol at IETF CCAMP (or OIF/ITU-T equivalentprotocols): – 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 todaybandwidth needs
– Hitless bandwidth modification, …
• Choice of deployment/service provisioning models – Static Overlay
– Dynamic Overlay
– Partial/Full Peer Model
– Centralized/Distributed Routing and Provisioning
GMPLS Th tGMPLS Th t
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 40/41
40
GMPLS: ThreatsGMPLS: Threats
• Carriers are reluctant to deploy distributedrouting/resource provisioning architectures for thetransport 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 playhere !)
– Need for robust, stable platforms
• Short term: Low investments of manufacturers
7/27/2019 Core Networks Evolution-UY
http://slidepdf.com/reader/full/core-networks-evolution-uy 41/41
Thank you for your attentionThank you for your attention