Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Giorgio Ventre » 12.Multi Protocol Label Switching


MultiProtocol Label Switching

  • Un modello di overlay per IP-su-ATM
  • Routing Vs Switching
  • Label MPLS
  • Label Switched Path
  • Il traffic Engineering
  • Resource reSerVation Protocol

IP: “Best-Effort Philosophy”

  • Ben progettata, non è necessario realizzarla nei dettagli.
  • Realizzazione: non può predire il futuro.
  • Decisioni Architetturali:
    • Realizzarla in maniera ragionevole
    • Realizzarla in maniera flessibile
    • Realizzarla in modo estensibile

ATM – Il “sogno” dei perfezionisti

  • Orientata alla connessione
  • Fa qualunque cosa e lo fa bene
  • Ha anticipato gli usi futuri.
  • Filosofia contrastante rispetto a IP

Un modello overlay per IP-su-ATM

  • Obiettivo: consentire IP su rete ATM
  • Perché? Gli switch ATM offrono buone performance, comportamento prevedibile e servizi (CBR, VBR, ecc)
  • Usando i circuiti virtuali di ATM la rete virtuale può essere “ringegnerizzata” senza cambiare la rete fisica.
  • Benefici:
    • Pieno controllo del traffico
    • Statistiche per ogni circuito
    • Flussi di traffico sui link più bilanciati

Modello Overlay

  • Il core ATM è formato da un anello di router
  • I PVC sono sopra la rete fisica

Mappare il livello dati di IP su ATM

  • Una varietà di server per la risoluzione degli indirizzi
    • ATMARP (RFC 1577), LANE, BUS, MPOA, NHRP ecc.
    • Utilizzo di circuiti virtuali pt-pt e pt-mpt separati coi server
    • Server multipli e VC di backup per la tolleranza ai guasti
    • Servizi separati per ogni dominio logico
  • Incongruenza tra il subnetting in IP e la rete ATM

Mappare il livello controllo di IP (es. OSPF) su ATM

  • OSPF prevede che le subnet siano pt-pt o abbiano capacità di broadcast
  • ATM e un mezzo Non-Broadcast Multiple Access (NBMA)
    • Segmenti NBMA supportano diversi router con VC pt-pt ma non supportano capacità di data-link broadcast/multicast
    • Ogni VC è costoso
  • Due modelli per OSPF
    • Modello Non-Broadcast Multiple Access (NBMA)
    • Modello punto-multipunto (pt-mpt)

Routing vs Switching

  • Routing: basato sul concetto di “indirizzo”
    • Operazione di ricerca
    • Complessità come O(log2n)
  • Switching: basato sul concetto di “numero di circuito”
    • Operazione di indicizzazione
    • Complessità come O(1)
    • Veloce e scalabile per grandi reti e grandi “spazi” degli indirizzi
  • Queste distinzioni sono applicabili per qualsiasi data-link: ATM, Ethernet, SONET

Il Routing IP lo Switching IP

  • Sulla rete ATM:
    • I router IP utilizzano indirizzi IP
      • Riassemblano i datagrammi IP dalle celle
  • Gli switch IP usano i numeri dei VC di ATM
    • “Commuta” celle
    • Non è necessario riassemblare i datagrammi IP

MPLS: il meglio dei due mondi


La novità di MPLS: Routing all’Edge, Switching nel core


La terminologia MPLS

  • LDP: Label Distribution Protocol
  • LSP: Label Swirched Path
  • FEC: Forwarding Equivalence Class
  • LSR: Label Switching Router
  • LER: Label Edge Router (termine utile ma non nello standard)
  • MPLS è “multi-protocollo” sia in termine di protocolli supportati SOPRA e SOTTO nello stack protocollare!

Header MPLS

  • Il pacchetto IP è INCAPSULATO nell’header MPLS e inviato sotto al LSP
  • Il pacchetto IP è ripristinato alla fine del LSP dal egress router
    • Il TTL è aggiustato per default

Concetti sullo stack label MPLS

Permette tunnel innestati, che sono opachi, cioè che non conoscono i protocolli dati trasportati

Permette tunnel innestati, che sono opachi, cioè che non conoscono i protocolli dati trasportati


Header MPLS

  • Label (etichetta)
    • Usata per associare il pacchetto al LSP
  • Experimental bit
    • Assegna una priorità nelle code al pacchetto (CoS)
  • Stacking bit: permette “stack” di label
    • Obiettivo: innestare tunnel!
  • Time to Live
    • Copiato dal TTL IP

Incapsulamento di Label


Un esempio di inoltro con MPLS

  • Un pacchetto IP destinato a 143.112.1.5/32 arriva al nodo SF
  • SF ha una rotta per 134.112/16
    • Il prossimo hop è LSP per NY

Un esempio di inoltro con MPLS

SF “appende” un header MPLS al pacchetto IP e lo invia al primo router di attraversamento sul percorso

SF “appende” un header MPLS al pacchetto IP e lo invia al primo router di attraversamento sul percorso


Un esempio di inoltro con MPLS

  • Poiché il pacchetto arriva a Santa Fe con un header MPLS, Santa Fe lo inoltra usando le tabelle di inoltro MPLS
  • Le tabelle di inoltro MPLS derivano dalle tabelle di switching mpls.0

Un esempio di inoltro con MPLS

  • Il pacchetto arriva al penultimo router con label 0
  • L’egress router vede la label 0 e toglie l’header MPLS
  • L’egress router inoltra il pacchetto secondo procedure IP standard

Label Setup/Signaling: MPLS usa i protocolli di routing IP


Un generico inoltro IP


Distribuzione delle Label in MPLS


Label Switched Path (LSP)


Un generico LSP Vanilla


Explicitly Routed (ER) – LSP


ER-LSP


Vantaggi del ER-LSP

  • Gli operatori hanno maggiori flessibilità in termini di routing (policy-based, QoS-based)
  • È possibile utilizzare altre rotte oltre ai shortest path (percorsi brevi)
  • È possibile calcolare rotte basate su vincoli così come ATM è basato su database di tipologie distribuito

Questioni aperte sul ER-LSP

  • Due opzioni per la segnalazione proposte nello standard
    • CR-LDP
      • LDP + Explicit Route
    • RSVP Extention
      • Traditional RSVP + Explicit Route + Scalability Extentions
  • Non si risolverà velocemente, ma sarà il mercato che probabilmente deve risolverlo

Ingegnerizzazione del Traffico (Traffic Engineering – TE)

  • TE: “…quell’aspetto dell’ingegnerizzazione della rete Internet che tratta questioni di valutazione e ottimizzazione delle performance delle operazioni della rete IP…”
  • Due sottoproblemi:
    • Definire un aggregato di traffico
    • Mappare il traffico aggregato su un percorso esplicito

Perché TE non con OSPF/BGP?

  • I protocolli di routing in Internet sono disegnati per scoprire un solo path
    • Limiti:
    • Le performance sono limitate ad un singolo percorso basato su approccio shortest path
      • Tutti i flussi ad una specifica destinazione sono mappati in un singolo percorso
    • Necessità di mappare il traffico su differenti percorsi
    • Cambiando i parametri cambiano le rotte e cambia il traffico mappato sulle rotte
    • Comportano traffico di controllo extra, problemi di convergenza e instabilità
  • In sintesi: in OSPF/BGP accoppiamento tra mappatura del traffico e disponibilità di path
    • MPLS disaccoppia invio traffico dal setup del path

TE con MPLS

Creare path unidirezionali senza l’uso del shortest path di IGP

Creare path unidirezionali senza l'uso del shortest path di IGP


TE con MPLS

Il prefisso IP (o traffico aggregato) può ora essere limitato al LSP MPLS

Il prefisso IP (o traffico aggregato) può ora essere limitato al LSP MPLS


Traffico aggregato: Forwarding Equivalence Class

  • FEC: un insieme di pacchetti trattati allo stesso modo
  • Il concetto di FEC fornisce uno strumento flessibile e scalabile
  • MPLS assegna la FEC all’ingresso delle rete

Segnalazione in un approccio TE per MPLS

  • Caratteristiche:
    • In MPLS la scelta del path è ortogonale al problema di mappare il traffico sulle rotte
    • Il segnalamento mappa identificativi globali (indirizzi IP) in identificativi locali (label)
    • FEC per meccanismi di aggregazione del traffico, label stacking per tunnel multilivello
  • Questioni:
    • Richiede un aggiornamento estensivo della rete
    • Impossibile per routing interdominio attraverso differenti organizzazioni

RSVP: Resource reSerVation Protocol

  • Un generico protocollo di segnalazione per QoS
  • Un protocollo di controllo internet
    • Usa IP come “livello rete”
  • Originariamente disegnato per protocolli host-to-host
  • Usa IGP per determinare i path
  • RSVP non è:
    • Un protocollo per trasporto dati
    • Un protocollo di routing
  • RFC 2205

RSVP: Segnalazione in Internet

  • Crea e mantiene lo stato della prenotazione distribuita
  • Disaccoppiato dal routing e dai modelli di multicast IP
    • Gli alberi di multicast sono realizzati dal protocollo di routing non da RSVP
  • Caratteristica chiave di RSVP
    • Inizializzato dal receiver: per multicast
    • Soft-state: la prenotazione va in timeout senza un refresh
  • Gli ultimi percorsi scoperti attraverso messaggi “PATH” e usati da messaggi “RSVP”
    • Dettato dalla necessità di disaccoppiare dal routing IP e supportare il multicast

Esempio di RSVP Path Segnaling

Il protocollo di segnalamento imposta un path da SF a NY, riservando banda lungo il percorso

Il protocollo di segnalamento imposta un path da SF a NY, riservando banda lungo il percorso


Esempio di RSVP Path Segnaling

Una volta che il path è stato fissato, il protocollo di segnalamento assegna un numero di label su percoso inverso da NY a SF

Una volta che il path è stato fissato, il protocollo di segnalamento assegna un numero di label su percoso inverso da NY a SF


Call Admission (ammissione di chiamata)

  • La sessione deve dichiarare i sui requisiti di QoS e caratterizzare il traffico che intendo inviare
  • R-spec: definisce i requisiti di QoS
  • T-spec: definisce le caratteristiche del traffico
  • È necessario un protocollo di segnalamento per portare R-spec e T-spec in tutti i router in cui è necessaria la prenotazione delle risorse: RSVP è un possibile candidato
  • I router accettano la chiamata in base a R-spec e T-spec e alle risorse allocate per le altre chiamate

Estenzioni MPLS per RSVP

  • Oggetti per messaggi PATH e RESV
    • Explicit Route Object (ERO)
    • Label Request Object
    • Label Object
    • Record Route Object
    • Session Attribute Object
    • Tspec Object
  • Per maggiori dettagli sul contenuto degli oggetti:
    • draft-ietf-mpls-rsvp-lsp-tunnel-04.txt
    • Estenzioni per RSVP dei Tunnel LSP

Cenni sulle reti SDH

  • Lo standard SDH
  • La struttura del livello SDH
  • Componenti SDH
  • Struttura della frame SDH
  • STM
  • Differenze tra Sonet e SDH
  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93