MPLS MPLS MPLS

(1)

RETI DI CALCOLATORI II

Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine

Prof. MARIO BALDI Facoltà di Ingegneria

Politecnico di Torino

© 2003 Pier Luca Montessoro – Mario Baldi (si veda la nota a pagina 2) 2 Questo insieme di trasparenze (detto nel seguito slide) è protetto dalle leggi sul copyright e dalle disposizioni dei trattati internazionali. Il titolo ed i copyright relativi alle slides (ivi inclusi, ma non limitatamente, ogni immagine, fotografia, animazione, video, audio, musica e testo) sono di proprietà degli autori prof. Pier Luca Montessoro, Università degli Studi di Udine, e prof. Mario Baldi, Politecnico di Torino.

Le slide possono essere riprodotte ed utilizzate liberamente dagli istituti di ricerca, scolastici ed universitari afferenti al Ministero della Pubblica Istruzione e al Ministero dell’Università e Ricerca Scientifica e Tecnologica, per scopi istituzionali, non a fine di lucro. In tal caso non è richiesta alcuna autorizzazione.

Ogni altro utilizzo o riproduzione (ivi incluse, ma non limitatamente, le riproduzioni su supporti magnetici, su reti di calcolatori e stampe) in toto o in parte è vietata, se non esplicitamente autorizzata per iscritto, a priori, da parte degli autori.

L’informazione contenuta in queste slide è ritenuta essere accurata alla data della pubblicazione. Essa è fornita per scopi meramente didattici e non per essere utilizzata in progetti di impianti, prodotti, reti, ecc. In ogni caso essa è soggetta a cambiamenti senza preavviso. L’autore non assume alcuna responsabilità per il contenuto di queste slide (ivi incluse, ma non limitatamente, la correttezza, completezza, applicabilità, aggiornamento dell’informazione).

In ogni caso non può essere dichiarata conformità all’informazione contenuta in queste slide.

In ogni caso questa nota di copyright e il suo richiamo in calce ad ogni slide non devono mai essere rimossi e devono essere riportati anche in utilizzi parziali.

Nota di Copyright

MPLS MPLS MPLS

Argomenti della lezione

Î MPLS

ÎPrincipi di base ÎApplicazioni

MPLS

Multi-Protocol Label Switching

L’idea di base

ÎInoltrare i pacchetti in base ad un’etichetta (label)

ÎInvece che sull’indirizzo IP di destinazione

Label Pacchetto IP

(2)

Perchè?

ÎRicerche in tabella di inoltro (lookup) più veloci

ÎL’etichetta può essere usata come indice

ÎInvece che longest prefix matching

ÎTraffic engineering

Network Architecture

Label switch router (LSR)

Label edge router Ingress/egress LSR MPLS network

MPLS cloud

Label Switched Path (LSP)

Ingress LSR

Egress LSR

0 1

Label switching

D

0 2 1 4 3 In

0

21 3 0 2 1 3

0 1

2 0

2 A D X 0 0 1

1

Out 2 2 1

In Out 0

1 In Out

0 1

Elementi chiave di MPLS

Î“Intestazione” MPLS

ÎContiene l’etichetta

ÎProtocolli di routing potenziati ÎVincoli per la scelta dei percorsi ÎProtocolli per la distribuzione

delle etichette Æ segnalazione

MPLS introduce il paradigma connection oriented

nelle reti IP

(3)

Shim header

Livello 2 Pacchetto IP

Label Exp S TTL

20 bit 3 bit 1 8 bit

TTL: Time to live

Exp: Experimental bits (CoS) S: Bottom of stack

Intestazione MPLS

ATM e frame relay

ÎProtocolli di livello 2 connessi ÎEtichette MPLS nell’intestazione di

livello 2

ÎVCI/VPI (ATM) ÎDLCI (Frame relay)

Forwarding equivalence class (FEC)

ÎPacchetti che

ÎSeguono lo stesso percorso nella rete MPLS

ÎVengono trattati nello stesso modo da ogni LSR

Ricevono la stessa etichetta

Label binding

Lo switch a valle di un collegamento associa le etichette usate da quello a monte a

ÎPorta di uscita ÎNuova etichetta

Creazione degli LSP

Label binding statico

ÎTramite management ÎEquivalente a PVC ATM ÎNon scalabile

ÎNo interoperabilità tra sistemi di gestione

ÎImpossibile avere LSP tra gestori differenti

Label binding dinamico

ÎProtocol (IP) driven

ÎLa creazione di LSP è legata alla scoperta di route verso le destinazioni

ÎCreazione automatica di LSP ÎSegnalazione esplicita

ÎIniziato dai label edge router

(4)

Protocolli di routing

Usati per determinare l’instradamento degli LSP ÎGuidano le procedure di label

binding

ÎIn modo indiretto determinano l’instradamento dei pacchetti

Protocolli di routing

I protocolli esistenti ÎOSPF

ÎIS-IS ÎBGP-4

portano informazioni topologiche Sono potenziati per ...

Protocolli di routing

... portare informazioni su vincoli per il routing (constraint data) ÎCapacità dei collegamenti ÎUtilizzo dei collegamenti ÎDipendenze tra i collegamenti

ÎUsato per il recupero guasti

Protocolli di routing estesi Constraint based routing

è fondamentale per il supporto di

traffic engineering

ÎOSPF–TE ÎIS-IS–TE

Protocolli per la distribuzione delle etichette

Due alternative (incompatibili) ÎLabel distribution protocol (LDP)

ÎProgettato per lo scopo ÎResource reservation protocol

(RSVP)

ÎProgettato per allocare risorse in reti a servizi integrati

Hop-by-hop routing

Ogni switch decide il prossimo passo del percorso dell’LSP

ÎGli switch si accordano su corrispondenze tra

ÎEtichette di ingresso e uscita ÎEtichette e FEC

ÎSimile al routing per pacchetti IP

(5)

Explicit constraint based routing

ÎUn singolo switch può scegliere il percorso di un LSP

ÎPer esempio ingress LSR ÎExplicit routing

ÎLa scelta è basata sui vincoli ÎConstraint based routing

Distribuzione delle etichette

Deve essere modificata

ÎCR-LDP

ÎConstraint-based routing LDP ÎRSVP-TE

ÎRSVP for Traffic Engineering Abbinati a OSPF-TE e IS-IS-TE

Nuove possibilità

ÎTraffic engineering ÎQualità del servizio

ÎNon realizzata

ÎClassi di servizio differenziate ÎRecupero guasti veloce

ÎIn meno di 50 ms

Piano dati

Piano di controllo

Piano di controllo e piano dati

RIP IGRP

OSPF

BGP IS-IS

Routing data base Routing table Aggiornamento

continuo

IP

Piano dati

Piano di controllo

Piano di controllo e piano dati

RIP IGRP

OSPF

BGP IS-IS

Routing data base Forwarding table

MPLS

RSVPLDP

Segnalazione (instaurazione LSP)

Instaurazione di LSP

Applicazioni di MPLS

ÎTraffic Engineering

ÎAggiunta di Class of Service (CoS) e Quality of Service (QoS)

ÎNetwork scalability ÎSupporto delle VPN IP

(6)

Routing IP tradizionale

Traffico per D su percorso ottimale

Routing IP tradizionale

Traffico per D su percorso ottimale 4 link sovraccarichi

Routing IP tradizionale

Traffico per D su percorso ottimale 4 link sovraccarichi 9 link sottoutilizzati

Traffic Engineering is the Answer

ÎObjectives

ÎMap actual traffic efficiently to available resources

ÎControlled use of resources ÎRedistribute traffic rapidly and

effectively in response to changes in network topology

ÎParticularly as a consequence of line or equipment failure → protection ÎThis complements Network Engineering

ÎPutting network capacity where traffic is

D

Traffic Engineering

Permette di distribuire il traffico

D

Traffic Engineering

conge-No stione

Utilizzo uniforme

(7)

Non si può fare con il routing IP tradizionale?

Traffico per D su

percorso ottimale 4 link sovraccarichi 9 link sottoutilizzati

Basta scegliere i percorsi in base al carico

percorso ottimale link sovraccarichi link sottoutilizzati

Così però i link scarichi si caricano e

viceversa ...

Traffico per D su percorso ottimale link sovraccarichi link sottoutilizzati

... e le tabelle di routing cambiano ...

percorso ottimale link sovraccarichi link sottoutilizzati

D

...così come il carico dei link...

Traffico per D su percorso ottimale link sovraccarichi link sottoutilizzati

D

... e i percorsi cambiano di nuovo!!!

percorso ottimale link sovraccarichi link sottoutilizzati Instabilità!

(8)

Standardizzazione

ÎIETF - Internet Engineering Task Force

ÎMPLS working group ÎMPLS Forum

ÎConsorzio produttori ÎVelocizzare la diffusione ÎAspetti tralasciati da IETF

ÎVoMPLS, ADSL