•Multi Protocol Label Switching •Objectifs initiauxpansiot/enseignement/RHD/MPLS.pdf · –Connaissance du protocole supérieur ? –Possibilité de router message ICMP ... –À

RHD 2009 MPLS 1

MPLS

• Multi Protocol Label Switching• Objectifs initiaux

– accélérer commutation IP• « lenteur » de la commutation IP saut par saut• Cell switching router (Toshiba 94), IP switching

(Ipsilon 96), Tag switching (cisco fin 96), …• Création groupe IETF MPLS 12/96• Normalisation (début 2001 …)

– RFC 3031 (architecture), RFC 3036 (LDP), …

RHD 2009 MPLS 2

MPLS

• Idée– Insérer un label dans paquet (IP ou autre)– Construire une table (FIB) de commutation en

fonction du label• Label court : lookup rapide• Possibilité d’agréger des destinations• Unifier la commutation des paquets

– Unicast ordinaire longest match (@D)– Unicast avec ToS : exact match (@D +ToS)– Multicast exact match (@D, @S, int. Entrée)– Protocoles différents (IPv4, IPv6, …) : Mpls

RHD 2009 MPLS 3

MPLS : nouveaux objectifs

• Commutation de label =– forme de tunnel (encapsulation) =>– construire des chemins particuliers

• ingénierie de trafic, routage avec QoS• Ex : RSVP-TE, CR-LDP

– masquer le réseau traversé• VPN IP basés sur MPLS et BGP• interconnexion de LAN à travers réseau IP

– trame sur IP, VPLS

– extension à d’autres niveaux• λ MPLS, GMPLS

RHD 2009 MPLS 4

FEC

• Concept de Forwarding Equivalence Class– Tous paquets d’une FEC traités de la même façon

• Même interface sortie• Même NextHop• Même file attente (si QoS)• Ex : unicast classique FEC = préfixe• Granularité variable

– FEC grossier : préfixe réseau 192.168.0.0/18– FEC fin : flux RSVP @S, @D, port S, port D

RHD 2009 MPLS 5

FIB MPLS• 2 possibilités

• 1 table par entrée (portée label = lien)• 1 table globale (portée label = nœud)

(int entrée, label entrée) => (label de sortie, int sortie, NextHop, File)n

• n > 1 si multicast

• Quel équipement insére le premier label ?– Classification des paquets

• Comment construire la FIB ?• Comment insérer les labels dans des

paquets/trames?

RHD 2009 MPLS 6

Insertion des labels• RFC 3032 MPLS Label Stack encoding• Pile de labels (utilisé p.e. dans VPN BGP-MPLS)• Label codé sur 20 bits dans Label Entry de 32 bits

– Label (20), Cos (3), Stack (1), TTL (8)– Stack = 1 <=> fond de pile

• Quelques labels réservés– 0 : IPv4 Explicit Null (fond de pile) => oblige à POP et

traitement IPv4– 1 : Router Alert Label (pas au fond) => examen spécial– 2 : IPv6 Explicit Null– 3 : Implicit Null (pas dans la pile) distribué pour forcer POP

RHD 2009 MPLS 7

Labels• Insertion ethernet

– @D,@D, ether=8847, label(s), network layer• Possible LLC/SNAP

– Remarque :• ethertype d’origine 0800 (IPv4) 86DD (IPv6), … perdu• Doit être déductible du label ou du network layer

• Insertion ATM– Réutilisation hard ATM pour MPLS

• => label dans entête cellule– Label sommet stack dans VPI,VCI (pas de TTL)

• Permet réutiliser commutation cellule• Stack complet dans paquet AAL

RHD 2009 MPLS 8

Encapsulation• TTL initialisé à TTL IP entrant

– Décrémenté (si possible) => détection de boucle• Problème des messages ICMP

– Connaissance du protocole supérieur ?– Possibilité de router message ICMP

• Adresse niveau IP peut être non routable (p.e. privée)• Possibilité :

– générer un paquet ICMP, et lui donner le même label stack– (sauf TTL)– le paquet « descend » jusqu’à l’Egress qui retransmet à la source

• Ex :– Problème de TTL exceeded (traceroute)– Problème de Path-MTU discovery

RHD 2009 MPLS 9

Commutation (FIB)• 3 structures

– NHLFE Next Hop Label Forwarding Entry• Indique

– Prochain saut– Opérations à effectuer sur pile de label

» Remplacer sommet pile SWAP (usuel)» Supprimer sommet pile POP» ex : sortie domaine Mpls : Egress router» Remplacer puis empiler 1 ou +sieurs labels PUSH

– Infos spécifiques au lien» Adresse mac , …

RHD 2009 MPLS 10

Commutation (2)

• ILM Incoming Label Map– Pour paquets avec label– label entrée (et int) => 1 ou +sieurs NHLFE

• Pour load balancing multipath• 1 seul NHFLE choisi

• FEC to NHFLE map– Pour paquets non labelés– Entrée de domaine Mpls : Ingress router– Insertion du premier label en fonction de la FEC

RHD 2009 MPLS 11

Construction des tables

• Protocoles de routage « classiques »– (A) Mapping FEC à NextHop (FIB IP)

OSPF, RIP, BGP, PIM, …

• Création d’association– (B) FEC <-> Label

• Distribution association– (A) +(B) => ILM + NHLFE

RHD 2009 MPLS 12

Association

• Association FEC <-> label– Locale (décidée localement)– Distante (décidée par voisin)– Les 2 voisins doivent être d’accord

• signalisation– Création upstream ou downstream

• Choix MPLS : downstream

RHD 2009 MPLS 13

Déclenchement association

• Deux méthodes– Méthode Control Driven

• Événement proto routage– OSPF recalcule table– Réservation RSVP– PIM join/prune …

• Stable (indépendant trafic)• Nombreuses associations inutiles

RHD 2009 MPLS 14

Déclenchement association (2)

• Méthode Data driven– À la détection d’un nouveau flux– Pas d’association inutile– Que se passe-t-il pour un paquet sans

association ? (réseau hybride)

RHD 2009 MPLS 15

Distribution des labels

• Par protocoles de routage (piggybacking)– Possible avec vecteur de distance ou

chemins (RIP, BGP)• Annonces suivent chemin inverse données

– Peu compatible avec état des liens• Inondation des annonces

• Par protocoles spécifiques (LDP)

RHD 2009 MPLS 16

Architecture• LSR Label Switch Router

– Routeur capable de commuter des paquets par label• Domaine MPLS

– Ensemble de LSR qui échangent• Des paquets avec label et des infos sur les associations• ~ domaine de routage

– Pour une FEC• Pour une entrée Ingress

– en général une seule sortie Egress– LSP (Label Switched Path) de Ingress vers Egress

• En général N Ingress utilisent la même sortie– 2 solutions

» 1 arbre : LSP-tree» ou bien N LSP indépendants

RHD 2009 MPLS 17

LSR et LSP merge

• Label merge : pour une même FEC– deux entrées (incoming label)

• => un seul NHFLE (et donc un seul label)• en général possible pour un routeur IP

• Si label merge impossible :– plusieurs LSP convergent vers Egress

même FEC, mais labels différents sur un lien

– Ex : switch ATM– Label <=> CV

• label merge <=> cellules de plusieurs CV « mélangées »incompatible avec AAL

• possibilité de merge sur le VP, mais VC ≠

RHD 2009 MPLS 18

Création des LSP• Mode ordonné

– Egress déclenche création de proche en proche versIngress

• Créer association si Egress ou si reçu association de l’aval• => Si LSP existe à l’Ingress, existe jusqu’à Egresss• Séquentiel => plus lent• Peut être Hop by Hop (chaque LSR décide prochain saut) ou• Explicite (~PNNI, source routing plus avantageux que IP)

• Mode indépendant– Chaque LSR décide pour ses liens entrants

• Construction en parallèle (+ rapide)• Risque incohérence

RHD 2009 MPLS 19

Exemple (downstream, ordonné)

R2R3

R5

R1

R4 R6 R7

Domaine MPLS

BGP Nouveau préfixe F

(F, L0)

(F, L1)(F, L3)

(F, L2)

(F, L4)

(F, L5)

BGP Nouveau préfixe F

BGP Nouveau préfixe F

BGP Nouveau préfixe F

R4L1,L2 -> R6, SWAP(L0)

R6L0 -> R7, POP

R5F -> R4, PUSH(L2)L5 -> R4, SWAP(L2)R2L3,L4 -> R4, SWAP(L1)

L5 inutilisé

RHD 2009 MPLS 20

Distribution des labels : LDP

• LDP Label Distribution Protocol– RFC 3036– Divers messages pour gérer adjacences entre

LSR voisins• Découverte adjacences (Hello) UDP, périodique• Établissement de session TCP• « hard state » : pas de de rafraîchissement cyclique

RHD 2009 MPLS 21

LDP : Associations– Label Advertisement : 4 commandes

• Label Request(FEC) (descendant)– Nouvelle FEC ou nouveau NH (ou commande)

• Label Mapping(FEC, Label) (montant)– Réponse à request ou spontané

• Withdrawal(FEC, Label)– Plus de route pour FEC

• Release(Label)– Plus besoin du Label

RHD 2009 MPLS 22

Distribution (suite)• Mode libéral

– Garder les mapping(FEC, L) de LSR1Même si NH pour FEC ≠ LSR1Utilisables si NH(FEC) changeGaspille espace label

• Mode conservateursi NH(FEC) ≠ LSR, envoyer release(L) à LSR1

• Mode downstream on demand• Request descend depuis Ingress

• Mode unsollicited downstream• Pas de request, mapping initié par Egress (schéma)

Mode négocié lors établissement session

RHD 2009 MPLS 23

Exemple (LDP downstream on demand, ordonné)

R2R3

R5

R1

R4 R6 R7

Domaine MPLS

BGP Nouveau préfixe F

Map(F, L0)

Map(F, L1)Map(F, L3)

Map(F, L2)

Map(F, L4)

BGP Nouveau préfixe F

BGP Nouveau préfixe F

BGP Nouveau préfixe F

R4L1,L2 -> R6, SWAP(L0)

R6L0 -> R7, POP

R5F -> R4, PUSH(L2)

R2L3,L4 -> R4, SWAP(L1)

REQ(F)REQ(F)

REQ(F)

REQ(F)

REQ(F)

routes IPvers F

RHD 2009 MPLS 24

LDP : FEC

• FEC = suite d’éléments FEC– Élément FEC = préfixe ou adresse d’hôte– Prochain saut vers tous les éléments

• Doit être identique• Sinon POP (possibilité de pile)

LSR2LSR1

LSR4

LSR3 Préfixe P1

Préfixe P2

Agrégation P1,P2

Mapping(P1,L1)

Mapping(P2,L2)

Mapping((P1,P2),L3)POP

RHD 2009 MPLS 25

Contrôle de boucle

• Données : TTL (curatif)– élimination de paquets

• Construction de LSP (préventif)– Option configurable « loop detect »– incluse dans Request et Mapping– Hopcount TLV #LSR traversés– Path vector TLV (pour LSR non « merge capable »)

• Liste des LSR traversés– Message LDP « loop detected notification »

• HopCount max atteint ou• PathVector contient Id LSR local (ou max atteint)

RHD 2009 MPLS 26

Routeur/commutateurrouteur IP + LSR MPLS

RIB

FIB

Signalisation

Données

A, donnéesentrée

FC

Algo routage

sortiepaquet

configuration

Routage IPLDP

RIB IPLIB label IB

A = label

Commutation de labels

RHD 2009 MPLS 27

Ingénierie de trafic• Traffic Engineering

• RFC 2702, Requirements for Traffic Engineering Over MPLS,septembre 99

• 2 types d’objectifs– Orientés trafic (~qualité de service pour les flux)

• Pour certains flux (type d’applic., de client)• Contraintes de qualité de service (débit, délai,…)

– => routage basé sur destination + (QoS dispo / lien)?– Orientés ressources (bonne utilisation des ressources)

• Répartir les flux– Augmenter la bande passante totale utilisable– Et/ou limiter la congestion– => routage basé sur destination + (BP dispo ?)

RHD 2009 MPLS 28

Ingénierie de trafic (2)– Commutation des paquets

• basé sur critères supplémentaires• Difficile à obtenir avec routage saut par saut

– Routage source (peu efficace en IP)– Marquer (épingler) la route (route pinning)

• MPLS : LSP = route « marquée »– Signalisation spécifique (RSVP-TE ou CR-LDP)– Utilisation différente des protocoles de routage

» Calcul à la source (à la demande ?)» Calcul par serveur

PCE : Path Computing Element

RHD 2009 MPLS 29

RSVP

• Principe de RSVP (architecture Intserv)– Source envoie RSVP-Path(Dest, FlowSpec)

• « marquage du chemin »• Nécessaire car routage non symétrique

– Récepteur(s) envoie RSVP-Resv• Réservation ressources sur le chemin• prend le chemin inverse (grâce marquage)

– Nécessite option Router Alert• Paquet Source => Dest. Traité par routeurs

RHD 2009 MPLS 30

RSVP

• Soft State (messages périodiques)– si route IP change

• réservation change au prochain Path/Resv

• RSVP de base :– utilise routes IP « classiques »

RHD 2009 MPLS 31

RSVP-TE (1)• RFC 3209, 3210 (décembre 2001)• Associe un label à un flux RSVP

– Mode downstream on demand• RSVP-Path(Label Request, Fec = D)

– En option objet route explicite• Liste de nœuds abstraits

– Strict (doit être voisin du précédent)– Lâche (loose) (pas nécessairement voisin direct)

• Nœud abstrait– décrit par Adresse IP ou Préfixe ou N° AS

– Réponse RSVP-Resv(Label, Fec)

RHD 2009 MPLS 32

RSVP-TE (2)• Changement dynamique de LSP

– Nouvelle capacité– Panne– Augmentation besoin des flux

• => modification sans perturbation– Identificateur de session– Changement de LSP : « make before break »

• Détecter liens communs ancien et nouveau LSP– même ident. de session

• Ne pas ajouter les BP (uniquement delta si ≠ )

RHD 2009 MPLS 33

Architecture de TE

• Automatisation des tunnels TE– Prise en compte des contraintes

• Bande passante– Connaître les ressources– Calculer des routes explicites

• Tenant compte ds ressources (CSPF)– => nouveau routage

• OSPF-TE

RHD 2009 MPLS 34

OSPF-TE

• RFC3630• Spécifie 1 nouveau LSA TE-LSA

– Bande passante totale– Bande passante totale réservable– Bande passante résiduelle

• Sur 8 niveaux de priorité– Groupe(s) administratif(s) (couleur)

• Peut appartenir à 1 ou plusiuers de 32 groupes– Métrique de TE (peut être ≠ métrique usuelle)

RHD 2009 MPLS 35

OSPF-TE (suite)

• Chaque routeur– Carte réseau avec BP disponible

• Sur chaque lien• Par priorité

• Lors de demande– Chemin de R1 à R2,

• bande passante D, priorité P

– Calcul (par la source ) du CSPF

RHD 2009 MPLS 36

OSPF-TE (suite)• Calcul (par la source A ) du CSPF

Constrained SPF shortest path first– Prendre le graphe du réseau– Éliminer les arêtes dont la BP résiduelle pour P

• Vérifie BPrésiduelle < Demande– Lancer l’algorithme de Dijkstra

• => tous les chemins calculés vérifient BP > D– Récupérer le chemin A=R1, R2, R3, …Rn=B– Réserver D sur ce chemin via RSVP-TE avec route explicite

• Si succès, chaque routeur envoie– LSA-TE mis à jour (BP résiduelle diminuée de D)

RHD 2009 MPLS 37

CR-LDP

• Constrained Routing LDP– RFC 3212-3214, janvier 2002

• Distribution « ordered on-demand downstream »– Label-Request => mapping

• Routage explicite (strict ou lâche) entre noeuds abstraits• Descripteur de trafic

– (peak rate, commited rated) (token bucket)• Priorité (possibilité de préemption)• « hard state » comme LDP ≠ RSVP soft state

– A été virtuellement abandonné au profit de RSVP-TE• Cf rfc3468 , bien que « proposed standard » de l’ietf

RHD 2009 MPLS 38

Demande R3 => R6 10M

R2R3

R5

R1

R4 R6 R7

Domaine MPLS

Demande pour F

R3 envoieRSVP Path route explicite R3 - R2 - R5 -R4 - R6 label request BP demandée 10M

R3 calcule Route expliciteR3 - R2 - R5 -R4 - R6(CSPF)50

5

40 20

60

Path

Path Path

Path

R6 renvoieRSVP Resv Label BP

Resv, L1Resv, L4

Resv, L3 Resv, L2

RHD 2009 MPLS 39

Biblio• [RFC 2702] Requirements for Traffic Engineering Over MPLS,

septembre 99• [MPLS] Davie, Rekhter, MPLS Technology and Applications,

Morgan Kaufmann, 2000.• [RFC3031] MPLS architecture, janvier 2001• [RFC 3032] MPLS label stack encoding, janvier 2001.• [RFC 3036] LDP specification, janvier 2001.• [QoSR] Z Wang, J Crowcroft, Quality of Service Routing for

Supporting Multimedia Applications, IEEE JSAC, Vol 14 N°7,sept 96.

• [RFC 3209, 3210] RSVP-TE, décembre 2001• [RFC 3212-3214] CR-LDP, janvier 2002