Core Networks Evolution-UY

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 [email protected]

Telecom Paris - ENST



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



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



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



5

Historical Perspective : Overlay NetworksHistorical Perspective : Overlay Networks

WDM

SDH

R2

R3

R1

IP

ATMC1

C2

C3

C4



6

WDMWDM

ATM ATM

SDHSDH

IPIP

Applications Applications

The Whole pictureThe Whole picture

P O S

I P O



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



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



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



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.



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



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


i1 26 i4 14

...


i1 14 i3 --



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).



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 ?



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



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?



17

Packet + Transport LayersPacket + Transport Layers

WDM

SDH

R

R

IP

ATM

TRANSPORT LAYER

PACKET LAYER



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.



Transport Network:Transport Network:

New trendsNew trends

(Automation in Transport Network)(Automation in Transport Network)



20

From IP over ATMFrom IP over ATM ……

IPIP

ATM ATM



21

…… Towards MPLS over OTNTowards MPLS over OTN

MPLSMPLS

OTNOTN

Required granularity change



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



23




• Phase 2 (Late 90’s) : Introduction of UNI to offercustomers the ability to set-up connections on

demand



24

Carrier Network AutomationCarrier Network Automation -- Phase 1Phase 1::Soft Permanent Virtual CircuitSoft Permanent Virtual Circuit

MANAGEMENT PLANE

USER PLANE

CONTROL PLANE



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)



26




• Phase 2 (Late 90’s) : Introduction of UNI to offercustomers the ability to set-up connections ondemand – “Bandwidth on demand”

– Example of usage: Grid



ASON: Control Plane for the Optical Network ASON: Control Plane for the Optical Network



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,…



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.



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



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



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



Generalizing MPLSGeneralizing MPLS



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,…)



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.



GG--MPLS :MPLS :

Main Open Issues and ChallengesMain Open Issues and Challenges



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



GMPLS:GMPLS:

Opportunities and ThreatsOpportunities and Threats

GMPLS O i iGMPLS O t iti



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



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



Thank you for your attentionThank you for your attention

Core Networks Evolution-UY

Documents

Transcript of Core Networks Evolution-UY