Multi Protocol Label Switching (MPLS) Alfio Lombardo Many uses of the Internet require particular levels of service to be supplied. For example, voice traffic requires low delay and very small delay variation. Video traffic adds the requirement for high bandwidth. Customers increasingly demand service contracts that guarantee the performance and availability of the network. In the past, in order to meet these requirements, network providers have had to over-provision their physical networks. MPLS offers a good way to avoid this issue by allocating the network resources to particular flows using constraint-based routing of LSPs. Virtual Private Networks Virtual Private Networks (VPNs) are an important feature of the service provided by ISPs to their customers. VPNs allow physically private networks to be extended to encompass remote sites by connecting them through the Internet. A customer in these circumstances expects to be able to preserve their IP addresses (which might not be globally unique) and to have the security of their data guaranteed. ISPs offer this service by ensuring that entry points to their network can exchange data only if they are configured as belonging to the same VPN. MPLS LSPs provide an excellent way to offer this service over an IP network. Meeting the Needs of the Modern Network VPNs have been addressed with additions to the BGP routing protocol, but IP has not provided good solutions to the requirements set out in the previous three sections. There has been no way of providing a guarantee of service, because the network is connectionless. Destinationbased routing along shortest path routes tends to overload some links and leave others unused. A popular solution is to use an overlay network, for example running IP over ATM PVCs. This is notoriously hard to manage, because many resources must be configured at each router in the network, and because there are two distinct protocols to be configured. It also leads to scaling issues, with an order of n2 connections needed in a network with n nodes. MPLS allows the use of just one set of protocols in the network. Using MPLS to meet the aims described in the previous three sections while avoiding the problems described above requires a label distribution protocol that supports Explicit Routes and constraint-based routing. There are currently two label distribution protocols that meet this definition: CR-LDP and RSVP. There is a debate about which of these protocols is preferable, which is most suitable for particular scenarios, and whether it is necessary to implement both of the protocols in an MPLS network. Since the LSPs set up to support Traffic Engineering, Service Contracts and VPNs are all configured in the same way for RSVP and CR-LDP (through the Traffic Engineering MIB), they are referred to as Traffic Engineered LSPs.

Background: integrazione del trasporto del traffico ISDN B-ISDN ATM (Asynchronous Transfer Model) - Elevata velocità di commutazione - Possibilità differenziare QoS - Meccanismi di gestione e controllo traffico (Traffic engineering)

Background: Asynchronous Transfer Mode http://www2.rad.com/networks/1994/atm/tutorial.htm http://www.iec.org/online/tutorials/atm_fund/ http://www.cne.gmu.edu/modules/atm/Texttut.html http://www.lanl.gov/lanp/atm.tutorial.html http://usuario.cicese.mx/~aarmenta/frames/redes/atm/tutorial1/tute.html

Background: Asynchronous Transfer Mode Assumptions ATM is a cell-based, connection-oriented transfer Methodology (label switching) ATM cell flow ATM net 1 2 3 1 2 3 5+48 bytes

Background: Asynchronous Transfer Mode ATM works on fiber optic fabric with extremely low error rates No error correction on data GFC: Generic Flow Control VPI: Virtual Path Id VCI: Virtul Circuit Id PT: Payload Type CLP: Cell Loss Priority HEC: Header Error Control

Background: Asynchronous Transfer Mode ATM uses Virtual Connection divided in two levels (required for switching) : Virtual Path Virtual Circuit ROUTING ATM is connection oriented. Before information is transferred from the terminal to the network, a logical/virtual connection is set. The header values are assigned to each section of a connection for the complete duration of the connection, and translated when switched from one section to another. Signalling and user information are carried on separate virtual channels Two sorts of connections are possible: * Virtual Channel Connections VCC * Virtual Path Connections VPC When switching or multiplexing on cells is to be performed, it must first be done on VPC ,then on the VCC. Virtual Channels This function is performed by a header sub field - VCI. Since the ATM network is connection oriented each connection is characterized by a VCI which is assigned at call set up. A VCI has only a local significance on the link between ATM node and will be translated in the ATM nodes. When the connection is released , the VCI values on the involved links will be released and can be reused by other connections. An advantage of this VCI principle is the use of multiple VCI values for multicomponent services. For instance video telephony can be composed of 3 components: voice , video and data each of which will be transported over a separate VCI. This allows the network to add or remove components during the connection. For instance, the video telephony service can start with voice only and the video can be added later. Virtual Path The network has to support semi-permanent connections, which have to transport a large number of simultaneous connections. This concept is known as virtual path. All ATM switches can be schematically described as follows. A number of incoming links ( I1,I2,..In) transport ATM information to the switch, where depending on the value of the header this information is switched to outgoing link (O1,O2,..On). The incoming header and the incoming link number are used to access a translation table. The result of the access to the table is an outgoing link and a new header value. VPI and VCI translation:This function is performed at the ATM switching and/or cross-connect nodes. At the VP switch, the value of the VPI field of each incoming cell is translated into a new VPI value of the outgoing cell. The values of VPI and VCI are translated into new values at a VC switch. ---- 2.2 Virtual Channels. The connection between two endpoints is called a Virtual Channel Connection, VCC. It is made up of a series of Virtual channel links that extend between VC switches. The VC is identified by a Virtual Channel Identifier, VCI. The value of the VCI will change as it enters a VC switch, due to routing translation tables. Within a virtual channel link the value of the VCI remains constant. The VCI (and VPI) are used in the switching environment to ensure that channels and paths are routed correctl The VCI (and VPI) are used in the switching environment to ensure that channels and paths are routed correctly. They provide a means for the switch to distinguish between different types of connection. There are many types of virtual channel connections, these include: User-to-user applications. Between customer equipment at each end of the connection. User-to-network applications. Between customer equipment and network node. Network-to-network applications. Between two network nodes and includes traffic management and routing. Virtual channel connections have the following properties: A VCC user is provided with a quality of service, QoS, specifying parameters such as cell-loss ratio, CLR, and cell-delay variation, CDV. VCCs can be switched or semi-permanent. Cell sequence integrity is maintained within a VCC. Traffic parameters can be negotiated, using the Usage Parameter Control, UPC. A detailed diagram showing the relationship between virtual channels and paths is shown below. 2.3 Virtual Paths. A virtual path, VP, is a term for a bundle of virtual channel links that all have the same endpoints. As with VCs, virtual path links can be strung together to form a virtual path connection, VPC. A VPC endpoint is where its related VPIs are originated, terminated or translated. Virtual paths are used to simplify the ATM addressing structure. VPs provide logical direct routes between switching nodes via intermediate cross-connect nodes. A virtual path provides the logical equivalent of a link between two switching nodes that are not necessarily directly connected on a physical link. It therefore allows a distinction between logical and physical network structure and provides the flexibility to rearrange the logical structure according to traffic requirements. This is best shown in the diagram above. As with VCs, virtual paths are identified in the cell header with the Virtual Path Identifier, VPI. Within an ATM cross-connect, information about individual virtual channels within a virtual path is not required, as all VCs within one path follow the same route as that path.

Gestione VPI - VCI Conn Id S1, … S9: switch ATM a, …d… : porte Supponiamo che S1 riceva su a una richiesta di connessione conVC Id 89. Supponiamo che S1 abbia gia’ disponibile un VP con S6 (VP Id 187); S1 rilancia sulla porta c con VPI fino a S6187 dopo aver commutato il VC Id in 42. Da quel momento il VC Id non e’ piu’ preso in considerazione dai Cross Connect (o switch ATM) Conn Id

Background: virtual channels and paths relationship Cross connect node

Background: Virtual Channel There are many types of virtual channel connections: User-to-user applications. Between customer equipment at each end of the connection. User-to-network applications. Between customer equipment and network node. Network-to-network applications. Between two network nodes and includes traffic management and routing. Virtual channel connections have the following properties: A VCC user is provided with a quality of service specifying parameters such as cell-loss ratio, CLR, and cell-delay variation, CDV. VCCs can be switched or semi-permanent. Cell sequence integrity is maintained within a VCC. Traffic parameters can be negotiated.

Background: Virtual Path Virtual paths are used to simplify the ATM addressing structure Within an ATM cross-connect, information about individual virtual channels within a virtual path is not required, as all VCs within one path follow the same route as that path

Background: Asynchronous Transfer Mode ATM can dynamically allocate bandwidth ATM can dynamically manage QoS specifications The devices to be connected to ATM networks might be very simple, like a telephone ATM is organized in a hierarchy, like today’s phone network

Background: ATM Service Classes Quality of Service Parameter constant bit rate (CBR) I dati sono accettati e trasferiti ad una velocità costante. Una certa quantità di banda è riservata e garantita dalla rete. This class is used for emulating circuit switching. The cell rate is constant with time. CBR applications are quite sensitive to cell-delay variation. Examples of applications that can use CBR are telephone traffic (i.e., nx64 kbps), videoconferencing, and television. variable bit rate–non-real time (VBR–NRT) Come CBR, la bandwidth è riservata ma non per velocità di picco. Permette picchi di trasferimento ma all’interno di un certo limite prestabilito (burst tolerance). I dati sono accettati senza restrizioni e trasportati se la bandwith è disponibile oppure sono rifiutati se non lo è. Non vi è nessuna garanzia di servizio di banda riservata. This class allows users to send traffic at a rate that varies with time depending on the availability of user information. Statistical multiplexing is provided to make optimum use of network resources. Multimedia e-mail is an example of VBR–NRT. variable bit rate–real time (VBR–RT) This class is similar to VBR–NRT but is designed for applications that are sensitive to cell-delay variation. Examples for real-time VBR are voice with speech activity detection (SAD) and interactive compressed video. available bit rate (ABR) Come UBR ma la rete provvede meccanismi di congestion-feedback. This class of ATM services provides rate-based flow control and is aimed at data traffic such as file transfer and e-mail. Although the standard does not require the cell transfer delay and cell-loss ratio to be guaranteed or minimized, it is desirable for switches to minimize delay and loss as much as possible. Depending upon the state of congestion in the network, the source is required to control its rate. The users are allowed to declare a minimum cell rate, which is guaranteed to the connection by the network. unspecified bit rate (UBR)

Background: QoS parameters. Technical Parameter Definition cell loss ratio (CLR) CLR is the percentage of cells not delivered at their destination because they were lost in the network due to congestion and buffer overflow. cell transfer delay (CTD) The delay experienced by a cell between network entry and exit points is called the CTD. It includes propagation delays, queuing delays at various intermediate switches, and service times at queuing points. cell delay variation (CDV) CDV is a measure of the variance of the cell transfer delay. High variation implies larger buffering for delay-sensitive traffic such as voice and video. peak cell rate (PCR) The maximum cell rate at which the user will transmit. PCR is the inverse of the minimum cell inter-arrival time. sustained cell rate (SCR) This is the average rate, as measured over a long interval, in the order of the connection lifetime. burst tolerance (BT) This parameter determines the maximum burst that can be sent at the peak rate. This is the bucket-size parameter for the enforcement algorithm that is used to control the traffic entering the network.

Background: QoS vs. Service class Class of Service CBR VBR–NRT VBR–RT ABR UBR CLR yes no CTD CDV PCR SCR BT flow control

Background: ATM Architecture The ATM Adaptation Layer, AAL, performs the necessary mapping between the ATM layer and the higher layers. This task is usually performed in terminal equipment, or terminal adaptors, TA, at the edge of the ATM network. The class of service are general concepts, but these they are mapped onto different specific AAL types. Class A: AAL 1. Class B: AAL 2. Class C & D: AAL 3/4. Class C & D: AAL 5. Below is a list of the defined AAL types. Contained with each type is a list of applications suited to that particular AAL. 2.4.1 AAL type 1. Circuit transport to support synchronous (e.g. 64KBit/s) and asynchronous (e.g. 1.5, 2 MBit/s) circuits. Video signal transport for interactive and distributive services. Voice band signal transport. High quality audio transport. AAL type 2. AAL 2 has not currently been defined, but services for this type may include: Transfer of service data units with a variable source bit-rate. Transfer of timing information between source & destination. AAL types 3/4. AAL 3 was designed for connection-orientated data, while AAL 4 for connectionless-orientated data. AAL5 ha lo stesso scopo di AAL3/4 cioè di permettere alle applicazioni di trasmettere dati con dimensioni dei datagrammi più ragionevoli dei 48 byte delle celle ATM. Il datagramma che si vuole inviare sulla rete viene aggiunto a un certo numero di byte di padding più altri 8 byte di trailer. I byte di padding sono tali per cui il datagramma più il padding più il trailer rappresenta un multiplo intero di 48 byte cioè della dimensione dell celle ATM vere e proprie. Il trailer ha 2 byte non utilizzati, 2 byte che indicano che indicano la lunghezza del pacchetto escludendo il padding ed il trailer ed infine 4 byte di CRC. AAL5 utilizza 1 bit dell’header della cella ATM per indicare la fine del pacchetto. The AAL is organised on two sublayers: The Convergence Sublayer. The Segmentation and Reassembly Sublayer.

Modelli di integrazione IP/ATM Modello overlay Modello integrato

Modello overlay (rfc 1483) Utilizzato a partire dalla meta’ anni 90 Utlizza PVC (Permanent Virtual Circuit) PVC di tipo UBR o ABR tra gli IP_Router Trasporto pacchetti su celle ATM attraverso AAL5 PVC ATM N(N-1)/2 PVC per maglia completa

Modello overlay: topologia fisica PVC setup: Segnal. ATM 3 Rete ATM 1 Intf In VPI/VCI Out 1 0/40 3 0/50 Switch ATM Router IP 1 Switch interface

Modello overlay: instradamento atm 0/0/1 VPI/VCI=0/40 Rete 195.31.235.0/24 Next Hop Interface R2 Intf In VPI/VCI Out 1 0/40 3 0/50 Intf In VPI/VCI Out 2 0/50 3 0/60 Segmentazione S1 S2 R2 R1 VPI/VCI=0/50 VPI/VCI=0/60 ATM 0/0/1 ATM 0/0/2 1 3 2 3 VPI/VCI=0/40 195.31.235.88 195.31.235.88 Riassemblaggio Commutazione ATM Host 195.31.235.88 172.16.12.10

Modello overlay: configurazione interfaccia router R1(config) # interface atm 0/0/1 R1(config) # ip address 172.16.12.1 255.255.255.252 R1(config) # pvc 0/40 R1(config) # abr 1000 500 R1(config) # encapsulation aal5snap Parametri PVC: PCR= 1 Mb/s MCR= 500 kb/s

Modello overlay:Segmentazione e riassembraggio ATM cell IP IP IP IP PVC ATM IP IP IP IP AAL5 AAL5 AAL5 AAL5 ATM ATM ATM ATM Fisico Fisico Fisico Fisico Ricostruzione pacchetti in tutti i router Reti completamente magliate

Modello overlay: vantaggi Allocazione di banda sui PVC ATM Differenziazione dei flussi di traffico ATM Possibilità di ingegnerizzare il traffico in rete

Modello overlay: ingegnerizzare il traffico in rete 195.31.235.0/24 195.31.233.0/24 PVC setup: Segnal. ATM Rete ATM atm 0/0/1 VPI/VCI=0/40 atm 0/0/2 VPI/VCI=0/90 Rete 195.31.235.0/24 195.31.233.0/24 Next Hop Interface R2 Switch ATM Router IP 1 Switch interface

Modello overlay: svantaggi Gestione di 2 reti differenti (ATM e IP) Limitata scalabilità (interfaccia SAR-ATM 622 Mbit/s) Cell tax Stress del protocollo di routing IP (elevato numero adiacenze elevato numero di messaggi di segnalaz. per configurare le tabelle dei router) Ridurre il numero di adiacenze: Modello Integrato

Modello integrato Gli switch ATM implementano funzioni di instradamento IP Switch IP+ATM Switch ATM Router IP Intelligenza: routing IP Intelligenza: SW ATM forum Inoltro: Longest-match lookup Inoltro: Commutazione di etichetta - Esegue funzioni di routing IP (es.: RIP, OSPF, …) - Forwarding con modalità ATM Risultato: rete IP dove i pacchetti vengono trasportati in celle ATM su collegamenti virtuali che seguono un percorso determinato da un protocollo di routing IP (es. RIP, OSPF, …)

Modello integrato: associazione delle etichette (label binding) Nel modello integrato il collegamento virtuale non puo’ essere realizzato dalla segnalazione ATM …. Quindi e’ necessario integrare nella componente di controllo dello Switch IP+ATM un meccanismo per associare al percorso individuato dal routing IP le etichette VPI/VCI

Modello integrato: associazione delle etichette (label binding) Prot. Routing IP: per raggiungere 195.31.235.0/24 R1 – IA1 – IA2 – R2 IA1 IA2 Richiesta: 195.31.235.0/24 Richiesta: 195.31.235.0/24 Richiesta: 195.31.235.0/24 R1 R2 VPI/VCI: 0/40 VPI/VCI: 0/50 VPI/VCI: 0/60 IA1 IA2 195.31.235.0/24 Definisce un circuito virtuale tra R1 e R2 assegnando delle etichette ATM al percorso individuato dall’instradamento IP

Modello integrato: IA1 IA2 R2 R1 Rete Next Hop Interface atm 0/0/1 VPI/VCI: 0/40 195.31.235.0/24 IA1 Intf In VPI/VCI Out 1 0/40 3 0/50 Intf In VPI/VCI Out 2 0/50 3 0/60 IA1 IA2 R2 R1 VPI/VCI=0/40 VPI/VCI=0/50 VPI/VCI=0/60 ATM 0/0/1 ATM 0/0/2 Riassemblaggio 195.31.235.88 195.31.235.88 Segmentazione Commutazione ATM Host 195.31.235.88

Modelli overlay e integrato: confronto PVC tra R1 e R2 realizzato con segnalazione ATM Coesitenza 2 protocolli di routing Adiacenza con router R2 Integrato PVC tra R1 e R2 realizzato con label binding protocol Protocollo di routing IP Adiacenza con switch IP+ATM Nota: nel modello Integrato il pacchetto IP viene riassemblato solo nei router IP “reali” , non negli swithc IP+ATM….

Adiacenze IP Modello “integrato” Modello “overlay”

MultiProtocol Label Switching protocol: Open issues Spreco di banda introdotto dalla segmentazione ATM Scalabilità interfaccia SAR ATM (segmentazione solo ai bordi della rete) Mancanza di uno standard multivendor MultiProtocol Label Switching protocol: MPLS

MPLS target Recepire il modello integrato Utilizzare diverse tecnologie di livello 2 Possibilità di ingegnerizzare traffico IP Supportare QoS in reti IP in accordo a DiffServ Offrire RVP

Tipo di pacchetti/trame MPLS: concetti base Introduce nelle reti IP (backbone) la commutazione di etichetta tipico del circuito virtuale Non è legato alla tecnologia di trasporto Non è conscio del contenuto dl trasporto . . . Ethernet Frame Relay ATM PPP Commutazione di Etichetta Pacchetti di livello 3 (IPv4, IPv6, IPX, …) Trame di livello 2 (PPP, Ethernet, …) Tipo di pacchetti/trame trasportati Livello 2 (Data Link) MPLS

Forwarding Equivalent Class La decisione di instradamento di un router può essere vista come appartenente a due passi logici: Ricavare dalle intestazioni del pacchetto le informazioni per classificare il pacchetto in una data FEC Utilizzare la FEC per ottenere il next hop dalla tabella FEC - NH

FEC: esempi IP Ricavare dalle intestazioni del pacchetto il Destination Address (FEC) Utilizzare la FEC per ottenere il next hop sulla base del Longest Match Prefix Applicato alla tabella di routing Generalizzazione FEC: Policy based routing FEC 1: pacchetti destinati alla rete 195.31.235.0 . . . FEC 2: pacchetti destinati con IP PRECEDENCE=111 FEC n: pacchetti destinati al terminale 145.50.1.2 con indirizzo sorgente 195.35.4.5 FEC NH FEC 1 1 FEC 2 2 n Tabella di routing IP (FEC-To-Next-Hop)

FEC: granularità Granularità grossa Granularità fine FEC a: pacchetti destinati alla rete 195.31.235.0 Granularità grossa FEC b: pacchetti destinati al terminale 145.50.1.2, porta 80, con indirizzo IP sorgente 195.35.4.5, porta sorgente 11782 Granularità fine

Generalizzazione FEC: Policy based routing Ricavare dalle intestazioni del pacchetto la FEC: dest addr.+ sourceadd.+ IP_TOS +... (Policy base routing) Utilizzare la FEC per ottenere il next hop Analizzare tutti i campi che determinano la FEC è molto oneroso se effettuato in tutti i router Analisi dei campi necessari solo nei router di accesso alla rete Associazione di una label alla FEC nei router di accesso Istradare in accordo alla label nei router interni alla rete

MPLS: modalità di funzionamento Pacchetto L2 L3 I nodi intermedi analizzano solo l’intestazione MPLS ed eseguono la traslazione di etichetta (label switching) Pacchetto Classificazione dei pacchetti all’entrata del Dominio MPLS (assegnazione ad una FEC) Pacchetto Il nodo in uscita dal dominio MPLS rimuove l’etichetta (Label Disposition) Consegna dei pacchetti al Livello 3 all’uscita dal Dominio MPLS IGP IGP IGP Il nodo in ingresso al dominio MPLS assegna l’etichetta in accordo alla FEC (Label Imposition) Pacchetto L1 IGP IGP Nota che MPLS non viene implementato ( a meno di casi particolari) nel dominio dei clienti. Ne segue che i pacchetti IP provenienti da un router in tale dominio devono essere elaborati a livello 3 (IP) dal primo router del dominio MPLS; Analogamente l’ultimo router del dominio MPLS deve necessariamente esaminare il pacchetto a livello 3 Router MPLS

MPLS: inoltro dei pacchetti MPLS non viene implementato nel dominio dei clienti I pacchetti MPLS arrivano a un nodo intermedio il quale cambia l’etichetta; il pacchetto viene quindi inoltrato al Next-Hop 195.31.235.78 56 195.31.235.15 195.31.235.78 & 195.31.235.15 sono associati alla FEC 195.31.235.0/24 I pacchetti IP arrivano alla rete MPLS e vengono etichettati FEC 195.31.235.0/24 195.31.235.78 195.31.235.78 98 197.26.15.94 195.31.235.15 R1 195.31.235.15 98 R2 R3 Rete MPLS

Label Switching Router Architettura di un router MPLS Label Switching Router Componente di Controllo = + Componente Dati L’architettura di un router MPLS (Label Switching Router) è divisa in due distinte componenti Controllo Dati (Forwarding)

Label Switch Router: componente di controllo Criteri per la definizione delle associazioni tra etichette e FEC (label bindings) Distribuzione delle associazioni tra etichette e FEC Protocollo di Routing IP (es. OSPF, IS-IS, BGP, PIM) consigliati Per problemi legati all’Ingegneria del traffico vengono usati protocolli di routing di tipo Link State Creazione/aggiornamento delle Tabelle di Instradamento Gestione delle associazioni etichette-FEC

Label Switch Router: componente dati 45 1 29 64 2 29

MPLS: architettura di rete ATM/FR POP SDH POP: Point of Presence Edge LSR: ha almeno una interfaccia non MPLS; oltre che le funzioni di un LSR di transito (LSR) ha il compito di assegnare/rimuovere le etichette. Synchronous Digital Hierarchy (SDH) Sito Cliente ATM/FR POP LSR Edge-LSR

MPLS: tab di routing e gestione etichette 45 ILM + LIB FTN + LIB 29 64 Edge-LSR Tabelle di Routing IP LSR Pacchetti di livello 3 (non etichettati) 29 NHLFE: Next Hop Label Forwarding Entry FTN: Fec To NHLFE (Next Hop Label Forwarding Entry) ILM: Incoming Label Map LIB: Label Information Base

Ho associato l’etichetta 29 alla FEC 195.31.235.0/24. MPLS:LIB IGP Ehi tu, 172.16.0.1, guarda che ho associato l’etichetta 45 alla FEC 195.31.235.0/24. Vedi di memorizzarlo nella tua LIB 195.31.235.0/24 175.16.5.2 29 45 Label 45  FEC 195.31.235.0/24 Ho associato l’etichetta 29 alla FEC 195.31.235.0/24. Lab 29 …. FEC 195.31.235.0/24 Label 29 172.16.5.2 172.16.0.1 Ehi tu, 175.16.0.1, guarda che ho associato l’etichetta 50 alla FEC 195.31.235.0/24. Vedi di memorizzarlo nella tua LIB 172.16.1.4 50 Label 50  FEC 195.31.235.0/24 FEC Label Loc. Label Rem. Prov. Ogni LSR riguardo alla conservazione delle associazioni FEC-etichette puo’ operare in 2 modi diversi: Liberale, conservativo (v Tofoni pag 37). Nel caso in figura il routing IP ha specificato che il next hop per l a FEC 195.31.235.0/24 e’ 172.16.5.2 Quindi nel LIB basterebbe mantenere la riga verde (modalita’ conservativa) Nella modalita’ liberale viene memorizzata anche la riga sottostante il che rendera’ la costruzione della tabella piu’ veloce in caso di cambio di instradamento. FEC 195.31.235.0/24 Label 29 64 29 172.16.1.4 192.106.248.0/24 172.16.5.2 70 172.16.1.4 . . . Interfaccia IP . . . 172.16.5.2 Identificativo LSR (una delle interfacce IP LIB

LIB (Cisco 3640) P1# show mpls ldp bindings 192.168.0.22/32, rev 53 local binding: label: 24 remote binding: lsr: 192.168.1.3:0, label: 25 remote binding: lsr: 192.168.1.2:0, label: 22 remote binding: lsr: 192.168.0.11:0, label: 27 remote binding: lsr: 192.168.0.12:0, label: 34 192.168.0.31/32, rev 31 local binding: label: 25 remote binding: lsr: 192.168.1.3:0, label: 21 remote binding: lsr: 192.168.1.2:0, label: 24 remote binding: lsr: 192.168.0.11:0, label: 28 remote binding: lsr: 192.168.0.12:0, label: 35 192.168.0.32/32, rev 33 local binding: label: 26 remote binding: lsr: 192.168.1.3:0, label: 22 remote binding: lsr: 192.168.1.2:0, label: 25 remote binding: lsr: 192.168.0.11:0, label: 29 remote binding: lsr: 192.168.0.12:0, label: 36 Etichetta locale FEC Etichette remote Provenienze

FTN (negli Edge_LSR) Multicast/load bal. FEC-To-NHLFE (1) (k) NHLFE . . . Classificazione in FEC FEC2 NHLFE NHLFE . . . . . . . . . . . . FECn NHLFE NHLFE . . .

ILM (nei LSR) Multicast/load bal. Incoming Label Map (1) (k) NHLFE . . . Etichetta entrante L2 NHLFE NHLFE . . . . . . . . . . . . Ln NHLFE NHLFE . . .

Next Hop Label Forwarding Entry E adesso come e a chi li inoltro questi pacchetti ? FEC/Label - Next-Hop (interfaccia di uscita, label) - Operazioni sulla pila delle etichette Swap Pop Push - (opzionale) - Informazioni per il livello 2 - Modalità di trattamento del pacchetto - . . . 64 Ehi tu, guarda che le istruzioni per l’inoltro sono contenute nel NHLFE delle tabelle FTN/ILM NHLFE Tabella FTN/ILM

Costruzione ILM dinamica: la ILM viene costruita a partire dalla tabella di routing IP presente nel LSR e dalla LIB; in questo caso l’indicazione del Next-Hop proviene dal protocollo di routing adottato dalla rete (OSPF, IS-IS, ecc.). esplicita: la ILM viene costruita tramite un protocollo di segnalazione che permette di scrivere la riga corrispondente a ciascuna FEC; in questo caso il Next-Hop viene determinato esplicitamente (da un Operatore o automaticamente) attraverso un protocollo di segnalazione (es. RSVP-TE, CR-LDP, vedi capitolo su “Traffic Engineering”).

ILM CISCO 3640 P1# show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Untagged 10.1.1.2/32 0 Se0/0 point2point 17 Pop tag 192.168.0.12/32 0 Fa0/0 172.16.1.12 18 Untagged 172.16.2.0/24 0 Fa0/0 172.16.1.1 19 Untagged 172.16.3.0/24 0 Fa0/0 172.16.1.1 20 Untagged 172.16.12.0/24 0 Fa0/0 172.16.1.1 21 Untagged 172.16.13.0/24 0 Fa0/0 172.16.1.1 22 Untagged 172.16.23.0/24 0 Fa0/0 172.16.1.1 23 Pop tag 192.168.1.1/32 0 Fa0/0 172.16.1.1 24 19 192.168.1.2/32 0 Fa0/0 172.16.1.1 25 20 192.168.1.3/32 0 Fa0/0 172.16.1.1 26 28 192.168.0.21/32 0 Fa0/0 172.16.1.1 27 24 192.168.0.22/32 0 Fa0/0 172.16.1.1 28 25 192.168.0.31/32 0 Fa0/0 172.16.1.1 29 26 192.168.0.32/32 0 Fa0/0 172.16.1.1 30 Untagged 10.10.0.0/24 0 Se0/0 point2point 31 Untagged 10.1.11.0/24 0 Se0/0 point2point 32 Untagged 10.11.0.0/24 0 Se0/0 point2point La tabella ILM permette di associare ad una etichetta un insieme di NHLFE, ciascuno contenente opportune informazioni necessarie per l’inoltro del pacchetto (Nota: almeno un NHLFE deve essere sempre presente). Viene utilizzata quando ad un LSR arrivano pacchetti già etichettati. Tipicamente viene utilizzata nei LSR intermedi di un dominio MPLS. Come per le tabelle FTN, la presenza di più NHLFE associati a una sigola FEC può essere utile in caso di servizi multicast, o anche nel caso si voglia fare “load balancing” su più percorsi a costo minimo. In ogni caso, solo uno di questi NHLFE viene utilizzato per l’inoltro del singolo pacchetto. Etichetta entrante FEC Interfaccia uscente Fa=Fast Ethernet Se=Seriale Next-Hop Etichetta uscente

Costruzione ILM (dinamica) Etichetta NHLFE 29 52 64 72 Label: 45 Interfaccia: s0 Next Hop: 192.168.1.1 operazioni:…. Label: 99 Interfaccia: s1 Next Hop: 192.168.6.7 Label: 29 Interfaccia: e0 Next Hop: 192.168.5.5 Label: 44 . . . Rete Dest. Next-Hop 195.31.235.0/24 192.106.248.0/24 FEC Prov. 172.16.5.2 172.16.1.4 Loc. Rem. 45 70 50 LIB Tabella di routing IP Identificativo LSR 192.168.1.1 192.168.5.5

Peer LDP Ident: 192.168.1.3:0; Local LDP Ident 192.168.1.1:0 P1#sh ip route . . . . . . . . O IA 192.168.0.32 [110/75] via 172.16.13.3, 2d23h, Serial0/1 Tabella di routing IP P1#sh mpls ldp neighbor Peer LDP Ident: 192.168.1.3:0; Local LDP Ident 192.168.1.1:0 TCP connection: 192.168.1.3.11006 - 192.168.1.1.646 State: Oper; Msgs sent/rcvd: 15116/15088; ; Downstream Up time: 1w2d LDP discovery sources: Serial0/1, Src IP addr: 172.16.13.3 Addresses bound to peer LDP Ident: 192.168.1.3 172.16.23.3 172.16.3.3 172.16.13.3 Elenco delle interfacce di un LSR remoto P1#sh mpls ldp bindings 192.168.0.32/32, rev 40 local binding: label: 28 remote binding: lsr: 192.168.0.12:0, label : 36 remote binding: lsr: 192.168.0.11:0, label : 35 remote binding: lsr: 192.168.1.3:0, label : 30 LIB La costruzione della ILM, così come della FTN, può essere effettuata secondo due modalità: dinamica: la ILM viene costruita a partire dalla tabella di routing IP presente nel LSR e dalla LIB; in questo caso l’indicazione del Next-Hop proviene dal protocollo di routing adottato dalla rete (OSPF, IS-IS, ecc.). esplicita: la ILM viene costruita tramite un protocollo di segnalazione che permette di scrivere la riga corrispondente a ciascuna FEC; in questo caso il Next-Hop viene determinato esplicitamente (da un Operatore o automaticamente) attraverso un protocollo di segnalazione (es. RSVP-TE, CR-LDP, vedi capitolo su “Traffic Engineering”). La figura riporta un esempio di costruzione della ILM nel caso dinamico. Come si può notare, la costruzione risulta immediatamente da una “fusione” della tabella di routing IP convenzionale (sempre presente in ogni LSR) e dalla LIB. Ad esempio, la prima riga della ILM deriva dal fatto che dalla LIB si evince che il LSR ha associato localmente alla FEC 195.31.20/24 l’etichetta 29 mentre i LSR identificati dall’indirizzo 175.20.5.2 e 150.50.1.4 hanno associato e comunicato attraverso il protocollo di distribuzione delle etichette al LSR in esame, per la stessa FEC, le etichette 45 e 50 rispettivamente. Poiché dalla tabella di routing IP si evince che il Next-Hop per la FEC 195.31.20/24 è il LSR 175.20.5.2, collegato direttamente attraverso l’interfaccia “seriale 0”, segue immediatamente la prima riga della ILM. NOTA IMPORTANTE: nella realtà le cose funzionano un po’ diversamente in quanto nella LIB, associato al valore dell’etichetta remota vi è un identificativo del LSR remoto, mentre nella tabella di routing IP compare l’indirizzo IP dell’interfaccia a cui inoltrare il pacchetto (indirizzo che potrebbe essere diverso dall’identificativo del LSR remoto), per cui è necessaria una mappa che faccia corrispondere a ogni identificativo del LSR remoto tutti gli indirizzi delle interfacce di quel LSR. Nel protocollo di distribuzione LDP, questo viene risolto attraverso un opportuno messaggio (“Address Message”) attraverso il quale il LSR remoto comunica gli indirizzi di tutte le sue interfacce. Per i detlabelli, vedi il paragrafo “Label Distribution Protocol” nel capitolo “Distribuzione delle Etichette”. P1#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 28 30 192.168.0.32/32 876 Se0/1 point2point ILM

Operazioni sulle etichette Rimpiazza 88 con 99 64 88 … 64 99 … swap Elimina 99 64 88 … 99 X 64 88 … pop Rimpiazza 88 con 99 e inserisci 67 64 88 … 64 99 … 67 push

Label Switched Path LSP: Hop To Hop Esplicito (RSVP-TE; CR-LDP) R[u] 54 79 R[i] 45 58 29 R[4] 67 R[3] La connessione stabilita associando delle etichette ad un determinato percorso tra un LSR di ingresso e uno di uscita prende il nome di Label Switched Path. I LSP sono unidirezionali; i dati nella direzione opposta seguono un LSP differente…(come del resto il routing IP…). Il percorso seguito da un LSP puo’ essere determinato in accordo ad un protocollo di routing (LSP di tipo Hop to Hop ovvero ILM dinamica) o attraverso un esplicito protocollo di segnalazione (LSP esplicito ovvero ILM esplicita). Questi vengono realizzato per problematiche di Ingegneria del traffico: in pratica si decide di far fluire il traffico appartenente ad una FEC su un LSP differente da quello che sarebbe stato definito tramite il routing IP! R[2] LSP: Hop To Hop Esplicito (RSVP-TE; CR-LDP)

Limiti del routing IP convenzionale e dell’LSP Hop to Hop Ra 1,5 Mbit/s R2 Congestione ! R3 Rete 195.31.235.0/24 R1 Rb 1,5 Mbit/s R5 Percorso Ra  R3 R4 Percorso Rb  R3 Percorso Sottoutilizzato

LSP Nidificati Un LSP di livello m (m>1) e’ una sequenza di LSR - Che inizia con un LSR di ingresso che inserisce l’m-esima label della pila I cui router intermedi eseguono la commutazione di etichetta sulla etichetta aggiunta Che termina con un LSR di uscita dove la decisione di inoltro e’ basata sull’etichetta di livelli m-1 (o sull indirizzo IP se M=1) R[u] 72 29 R[i] 19 Un LSP di livello m (m>1) e’ una sequenza di LSR - Che inizia con un LSR di ingresso che inserisce l’m-esima label della pila - I cui router intermedi eseguono la commutazione di etichetta sulla etichetta aggiunta - Che termina con un LSR di uscita dove la decisione di inoltro e’ basata sull’etichetta di livelli m-1 (o sull indirizzo IP se M=1) 29 55 29 35 R[4] 29 45 R[3] pop swap R[2] push

Aggregazione indirizzi IP (CIDR): annunci delle reti/etichette Annunciati come 195.31.40.0/24 195.31.41.0/24 195.31.40.0/23 Rete = 195.31.40.0/24 Etichetta = 24 Rete = 195.31.41.0/24 Etichetta = 48 Rete = 195.31.40.0/23 Etichetta = POP Punto di aggregazione/disaggregazione dei prefissi LSR-B LSR-A LSR-C LSR-D Etichetta = 44

Aggregazione indirizzi IP (CIDR): inoltro pacchetti Annunciati come 195.31.40.0/24 195.31.41.0/24 195.31.40.0/23 Terminazione dell’LSP Lookup a livello 3 X POP LSR-A 24 195.31.40.1 44 195.31.40.1 195.31.40.1 X 195.31.41.1 44 195.31.41.1 LSR-D LSR-C 195.31.41.1 48 LSR-B

Egress-Targeted Label Assignment (LSP basati su edge LSR di uscita) L’LSR di ingresso dell’LSP sa che le due FEC devono seguire lo stesso LSP fino al LSR R[u] Rete MPLS 195.35.25.0/24 195.35.25.15 98 190.30.20.10 98 195.35.25.15 190.30.20.10 R[u] R[i] Vi sono situazioni in cui il LSR di ingresso di un LSP, R[i], sa che pacchetti appartenenti a FEC differenti devono seguire lo stesso percorso, ossia devono essere inoltrati attraverso lo stesso LSP, che termina in un LSR di uscita R[u] (es., pacchetti entranti nel LSR R[i] e destinati a reti diverse, ma tutte attestate al LSR R[u]). In tale situazione, la strategia migliore (più scalabile) è quella di assegnare tutte le FEC ad un unico LSP, riducendo in tal modo notevolmente lo spazio di etichette utilizzato. In altre parole, è possibile aggregare più FEC in una unica FEC caratterizzata dalla stesso LSR di uscita R[u]. Questa modalità di assegnazione delle FEC ad un unico LSP viene indicata nella RFC 3031 (MPLS Architecture) come “Egress-Targeted Label Assignment”. Il LSR di ingresso R[i] può associare una unica etichetta a tutte le FEC caratterizzate da una destinazione raggiungibile attraverso lo stesso LSR di uscita R[u], se e solo se valgono le seguenti due condizioni: 1. l’indirizzo di R[u] è presente nella tabella di routing IP del LSR R[i] come “host route”; 2. il LSR R[i] ha la possibilità di determinare in qualche modo che R[u] è il LSR di uscita del LSP utilizzato dai pacchetti di un particolare insieme di FEC. Vi sono vari modi per R[i] di detrminare che R[u] è il LSR di uscita per tutti i pacchetti di una determinata FEC. Ad esempio: - Se la rete adotta un protocollo di routing IP di tipo “link-state” e MPLS in una determinata area di routing, allora il protocollo di routing è in grado di far pervenire a R[i] informazioni sufficienti per determinare attraverso quali router di bordo sono raggiungibili le reti esterne all’area. - Se la rete utilizza il protocollo iBGP, allora R[i] riesce a determinare che i pacchetti di una determinata FEC lasciano la rete attraverso un determinato LSR che è il “BGP Next-Hop” per quella FEC; - È possibile utilizzare il protocollo di distribuzione delle etichette per passare informazioni circa le reti connesse ai vari LSR di bordo della rete; si ha in questo caso il vanlabelgio di non dipendere dal particolare protocolo di routing utilizzato. Il vanlabelgio principale della modalità di assegnazione delle etichette “Egress-Targeted Label Assignment” è che riduce considerevolmente l’utilizzo dello spazio di etichette e il numero di LSP nella rete. Una applicazione che vedremo in seguito, basata su questa modalità riguarda le reti BGP/MPLS.   Le due FEC vengono aggregate; viene utilizzato lo stesso LSP e quindi ai pacchetti viene associata una unica etichetta 190.30.20.0/24

Pacchetto MPLS consegnato al livello 2 (Eth., ATM, F.R., PPP, ecc.) Etichette TTL S Exp Label 8 1 3 20 Livello 1 Livello 2 Livello m . . . Pacchetto/Trama Pacchetto MPLS consegnato al livello 2 (Eth., ATM, F.R., PPP, ecc.)

Trasporto dei pacchetti MPLS su trama Liv. fisico Liv. 2 Pacchetto MPLS Liv. fisico Liv. 2 Pacchetto MPLS Liv. fisico Liv. 2 Pacchetto MPLS H 2 Header Livello 2 T 2 Trailer Livello 2

Trasporto dei pacchetti MPLS su ATM Etich. NHLFE 45 Etich. 55 Int. 2 … Int. 1 Int. Etich. NHLFE Etich. NHLFE 36 Etich. 45 Int. 1 … … … 1 55 Etich. 99 Int. 2 64 36 … … 64 VPI/VCI = 0/45 ILM ILM ILM VPI/VCI = 0/55 64 99 Non e’ possibile gestire i campi TTL, EXP R[1] R[3] R[2] MPLS MPLS AAL5 AAL5 ATM ATM ATM Liv. fisico Liv. fisico Liv. fisico

Identificazione del tipo di protocollo trasportato Il campo protocol del livello 2 indica “MPLS” MPLS non ha un campo “protocol” A ciascun tipo di protocollo trasportato viene dedicato un set di etichette

Distribuzione delle associazioni FEC/Etichette Possibili opzioni: incapsulare le etichette nei messaggi di protocolli di routing esistenti utilizzare uno specifico protocollo LDP: Label Distribution Protocol CR_LDP RVSP_TE LSP Esplicito CR_LDP: Constrained based Routing LDP Carring Label Information in BGP-4

Modalità di distribuzione e mantenimento delle associazioni Diverse modalità di distribuzione in accordo a: Direzione della distribuzione A quali LSR inviare le associazioni Quando inviare le associazioni Diverse modalità di mantenimento delle associazioni nella LIB Mantenere nella LIB tutte le associazioni Mantenere nella LIB le associazioni necessarie per l’inoltro dei pacchetti

Direzione della distribuzione : modalità downstream/upstream 195.31.235.0/24 Associazione locale FEC: 195.31.235.0/24 Etichetta: 80 Associazione locale FEC: 195.31.235.0/24 Etichetta: 80 Distribuzione FEC: 195.31.235.0/24 Etichetta: 80 Distribuzione FEC: 195.31.235.0/24 Etichetta: 80 R[1] R[2] R[2] R[3] Pacchetto 80 Pacchetto 80 R[1] R[2] R[2] R[3] (a): downstream (b): upstream

Modalità downstream (a) (b) 195.31.235.0/24 R[1] R[2] R[3] R[4] Associazione locale FEC: 195.31.235.0/24 Etichetta: 80 Associazione locale FEC: 195.31.235.0/24 Etichetta: 72 Associazione locale FEC: 195.31.235.0/24 Etichetta: 35 Distribuzione FEC: 195.31.235.0/24 Etichetta: 80 Distribuzione FEC: 195.31.235.0/24 Etichetta: 72 Distribuzione FEC: 195.31.235.0/24 Etichetta: 35 195.31.235.0/24 R[1] R[2] R[3] R[4] (a) Pacchetto 80 Pacchetto 72 Pacchetto 35 195.31.235.0/24 R[1] R[2] R[3] R[4] (b)

A quali LSR inviare le associazioni? Distribuzione con richiesta Ehi tu, guarda che mi serve una etichetta per la FEC 195.31.235.0/24 Richiesta 195.31.235.0/24 LSR 1 Associazione LSR 2 Downstream on demand

Distribuzione senza richiesta Ehi tu, guarda che ti stò inviando una etichetta per la FEC 195.31.235.0/24 Associazione 195.31.235.0/24 LSR 1 LSR 2 Downstream unsolecited

Quando inviare le associazioni Controllo: - indipendente: l’annuncio puo’ essere inviato in qualsiasi momento; - ordinato: l’annuncio puo’ essere inviato solo dopo aver ricevuto l’annuncio da parte degli LSR next hop.

Esempio: Controllo ordinato (4) Allocazione Etichetta(40) per FEC 50.1/16 (2) Allocazione Etichetta(50) per FEC 50.1/16 Richiesta: FEC 50.1/16 (3) R[3] Richiesta: FEC 50.1/16 (1) R[2] Etichetta: 40 (5) (6) Inserimento nella ILM Etichetta : 50 (7) R[1] (8) Inserimento nella ILM Downstream on-demand con controllo ordinato

Esempio: Controllo indipendente (4) Allocazione Etichetta(40) per FEC 50.1/16 Inserimento nella ILM (2) Allocazione Etichetta(50) per FEC 50.1/16 Richiesta: FEC 50.1/16 (3) Etichetta : 50 R[3] Richiesta: FEC 50.1/16 (1) R[2] Etichetta: 40 (5) (6) Inserimento nella ILM R[1] Downstream on-demand con controllo indipendente

Esempio: LSP 1 ILM ILM Etich. entrante I/F uscita Dest. Etich. uscente 50 1 40 40 1 50.1/16 FTN Dest. I/F uscita Etich. uscente 50.1/16 1 50 1 40 50.1/16 1 R[3] 50 1 R[2] 1 R[1]

Modalità di mantenimento nella LIB Modalita: - Liberale (Tutte le associazioni nella LIB) - Conservativa (Solo le associazioni ricevute dai Next Hop) Compatibilità tra le varie opzioni Downstream unsolecited + mod indipendente + mantenimento liberale Downstream on-demand + mod ordinata + mantenimento conservativo

Label Distribution Protocol Meccanismo di discovery Utilizzo di TCP (UDP per Hello) con porta 646 Uso codifica TLV

Usato per i LSP nidificati! Due LSR che utilizzano il protocollo LDP per lo scambio di associazioni etichetta-FEC vengono detti “LDP Peers” e si parla di “sessione LDP” esistente tra i due LSR per lo scambio delle associazioni. Etichetta 94  FEC 195.31.235.0/24 LSR A LSR B Sessione LDP Usato per i LSP nidificati! Fig. 3.5 (a) Due LSR che utilizzano il protocollo LDP per lo scambio di associazioni etichetta-FEC vengono detti “LDP Peers” e si parla di “sessione LDP” esistente tra i due LSR per lo scambio delle associazioni. Una singola sessione LDP permette lo scambio delle associazioni etichetta-FEC tra i due LSR agli estremi della sessione. La sessione può essere di tipo “single-hop” o “multi-hop”. Se la sessione è di tipo “single-hop” allora i due LDP Peers sono adiacenti l’un l’altro, ossia esiste un collegamento diretto (fisico o logico) fra i due. Se la sessione è di tipo “multi-hop” allora i due LDP Peers sono separati da altri LSR. Rete MPLS LSR A LSR B Etichetta 94  FEC 195.31.235.0/24 Sessione LDP

Messaggi LDP Notifica Discovery Annunci Sessione NOTIFICATION HELLO ADDRESS ADDRESS WITHDRAW LABEL MAPPING LABEL REQUEST LABEL ABORT REQUEST LABEL WITHDRAW LABEL RELEASE Sessione INITIALIZATION KEEPALIVE

Meccanismo di discovery Base Hello LSR C LSR A LSR B Rete MPLS Esteso LSR D Meccanismo base: utilizza IP address 224.0.0.2 e Hold Timer 15 s. Meccanismo esteso: utilizza indirizzo IP del router target e Hold Timer 45 s.

Sessioni LDP: apertura connessione TCP Ehi tu, guarda che per aprire la sessione LDP dobbiamo prima stabilire una connessione TCP SYN, Seq=n SYN, Seq=m, ACK=n+1 LSR 1 (attivo) LSR 2 (passivo) ACK=m+1 SE IP1>IP2 LSR1 attivo

Sessioni LDP: inizializzazione sessione Ehi tu, guarda che dobbiamo metterci d’accordo sui parametri della sessione LDP Initialization LSR 1 Initialization LSR 2 Versione protocollo Modalità di distribuzione Keepalive Timer Spazio VPI/VCI (ATM) Exponential backoff in caso di insuccesso

Sessioni LDP: KeepAlive Keepalive Timer Keepalive Timer LDP-PDU/Keepalive LDP-PDU/Keepalive LSR 1 LSR 2 HoldTimer= K * KeepAlive Timer K=3 Allo scadere di HoldTimer LSR chiude la connessione TCP

Annunci LDP: Address Porta TCP dest.: 646 IP TCP H ADDRESS Ehi tu, guarda che ti stò inviando un messaggio di ADDRESS per comu-nicarti gli indirizzi di tutte le mie interfacce IP TCP H ADDRESS Porta TCP dest.: 646

Annunci LDP: Label Request Ehi tu, guarda che ti stò inviando un messaggio di LABEL REQUEST perché mi serve una etichetta per la FEC 195.31.235.0/24 LABEL REQUEST H TCP IP LSR UpStr LSR DownStr Porta TCP dest.: 646

Annunci LDP: Label Mapping Ehi tu, guarda che ti stò inviando un messaggio di LABEL MAPPING per comunicarti che ho associato l’etichetta 35 alla FEC 195.31.235.0/24 IP TCP H LABEL MAPPING LSR UpStr LSR DownStr Porta TCP dest.: 646

Annunci LDP: Label Withdraw Ehi tu, ritiro quanto fatto in precedenza per la FEC 195.31.235.0/24; devi cancellare l’associazione FEC-etichetta che ti avevo inviato IP TCP H LABEL WITHDRAW LSR UpStr LSR DownStr Porta TCP dest.: 646

Annunci LDP: Label Release Ehi tu, guarda che ti stò inviando un messaggio di LABEL RELEASE perché mi è cambiato il Next-Hop per la FEC 195.31.235.0/24 e quindi l’associazione FEC- etichetta che mi hai inviato non mi serve più LABEL RELEASE H TCP IP LSR UpStr LSR DownStr Porta TCP dest.: 646

LDP - PDU + LDP PDU MSG n MSG 2 MSG 1 H TCP/UDP IP UDP solo per i 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | PDU Length | | LDP Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LDP PDU MSG n MSG 2 MSG 1 H + TCP/UDP IP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Message Type | Message Length | | Message ID | | | + + | Mandatory Parameters | | Optional Parameters | Lo scambio dei messaggi LDP avviene attraverso le LDP PDU (Protocol Data Unit), ciascuna delle quali può contenere più messaggi LDP. Le LDP PDU vengono quindi trasportate su una normale connessione TCP. Ogni LDP PDU è costituita da una intestazione (Header), indicata con H nella diapositiva, e un payload costituito da uno o più messaggi LDP (vedi prossime diapositive). L’intestazione contiene i seguenti campi: Version (16 bit): contiene la versione del protocollo; quella attuale è la 1. PDU Length (16 bit): specifica la lunghezza totale della PDU in byte, con esclusione dei campi “Version” e “PDU Length”; il valore massimo della lunghezza può essere negoziato durante la fase di inizializzazione della sessione LDP; prima di questa fase il valore massimo ammesso è 4096 byte. LDP Identifier (48 bit): identifica lo spazio di etichette utilizzato; i primi 4 byte costituiscono un identificativo del LSR, gli altri 2 un identificativo dello spazio di etichette; se il LSR utilizza uno spazio di etichette “globale” (indipendente dalle interfacce) questi 2 byte vengono posti a 0x0000. Il formato dei messaggi è costituito dai seguenti campi: U (1 bit): alla ricezione di un messaggio sconosciuto, U=0 significa che si deve ritornare un messaggio di errore a che ha originato il messaggio, U=1 significa che il messaggio deve essere semplicemente ignorato. Message Type (15 bit): specifica il tipo di messaggio. Message Length (16 bit): specifica la lunghezza totale (in byte) dei campi “Message ID”, “Mandatory Parameters” e “Optional Parameters”. Message ID (32 bit): identificativo del messaggio; serve a semplificare l’identificazione di un eventuale messaggio di notifica e/o errore. Mandatory Parameters (variabile): campo contenente i vari parametri necessari al messaggio (es. FEC, etichette, liste di indirizzi, ecc.); per alcuni messaggi può anche non esistere (es. messaggi “Keepalive); ogni parametro è codificato secondo lo schema TLV (Type-Length-Value). Optional Parameters (variabile): contiene eventuali parametri opzionali. UDP solo per i messaggi “Hello”

LDP Identifier 192.168.0.11 : 0 4 byte 2 byte Identificativo LSR Spazio di etichette Lo scambio dei messaggi LDP avviene attraverso le LDP PDU (Protocol Data Unit), ciacuna delle quali può contenere più messaggi LDP. Le LDP PDU vengono quindi trasportate su una normale connessione TCP. Ogni LDP PDU è costituita da una intestazione (Header), indicata con H nella diapositiva, e un payload costituito da uno o più messaggi LDP (vedi prossime diapositive). L’intestazione contiene i seguenti campi: Version (16 bit): contiene la versione del protocollo; quella attuale è la 1. PDU Length (16 bit): specifica la lunghezza totale della PDU in byte, con esclusione dei campi “Version” e “PDU Length”; il valore massimo della lunghezza può essere negoziato durante la fase di inizializzazione della sessione LDP; prima di questa fase il valore massimo ammesso è 4096 byte. LDP Identifier (48 bit): identifica lo spazio di etichette utilizzato; i primi 4 byte costituiscono un identificativo del LSR, gli altri 2 un identificativo dello spazio di etichette; se il LSR utilizza uno spazio di etichette “globale” (indipendente dalle interfacce) questi 2 byte vengono posti a 0x0000. Il formato dei messaggi è costituito dai seguenti campi: U (1 bit): alla ricezione di un messaggio sconosciuto, U=0 significa che si deve ritornare un messaggio di errore a che ha originato il messaggio, U=1 significa che il messaggio deve essere semplicemente ignorato. Message Type (15 bit): specifica il tipo di messaggio. Message Length (16 bit): specifica la lunghezza totale (in byte) dei campi “Message ID”, “Mandatory Parameters” e “Optional Parameters”. Message ID (32 bit): identificativo del messaggio; serve a semplificare l’identifica-zione di un eventuale messaggio di notifica e/o errore. Mandatory Parameters (variabile): campo contenente i vari parametri necessari al messaggio (es. FEC, etichette, liste di indirizzi, ecc.); per alcuni messaggi può anche non esistere (es. messaggi “Keepalive); ogni parametro è codificato secondo lo schema TLV (Type-Length-Value). Optional Parameters (variabile): contiene eventuali parametri opzionali. 192.168.0.11 : 0

LDP Identifier Hello R1:0 Hello R1:1 R[5] R[1] R[2] Hello R2:4 ATM R[5] Ser. R[1] ATM R[2] Hello R2:4 Hello R5:0 Eth. Hello R3:0 Hello R1:0 Hello R4:0 Eth. Eth. LDP prevede quattro categorie di messaggi: Discovery: a questa categoria appartiene il solo messaggio “Hello” che serve ad implementare il meccanismo di “Discovery”. Notifica: a questa categoria appartiene il solo messaggio “Notification” che serve a notificare eventuali situazioni di errore oppure a passare informazioni di servizio (es. Stato della connessione LDP, stato delle richieste pervenute attraverso altri messaggi, ecc.) Sessione: a questa categoria appartengono i messaggi “Initialization” e “Keepalive”; il primo contiene i parametri per inizializzare la sessione LSP (es. valore del “Keepalive time”, massima lunghezza della PDU, ecc.), il secondo è un messaggio praticamente vuoto il cui invio periodico, come già visto, serve a mantenere attiva la sessione LDP. Annunci: a questa categoria appartengono tutti i messaggi che servono allo scambio delle associazioni etichette-FEC; l’elenco dei messaggi è riportato nella diapositiva. I messaggi riportati nella diapositiva sono quelli ad oggi standardizzati nella RFC 3036. Poiché LDP è stato progettato per essere modulare, in futuro sarà possibile introdurre ulteriori messaggi senza intaccare l’impianto generale del protocollo. Ad esempio, l’estensione di LDP denominata CR-LDP, prevede la definizione di nuovi messaggi che servono a costruire LSP “explicitly routed” e a specificare eventual-mente il profilo di traffico trasportato da un determinato LSP. Nelle prossime diapositive verranno illustrati i messaggi più importanti. R[3] R[4]

Integrazione DiffServ-MPLS N flussi Dominio DiffServ/MPLS Edge-LSR Edge-LSR LSR DiffServ aggregazione dei flussi all’ingresso più flussi associati con una classe (identificata dal DSCP) MPLS più flussi associati con una sequenza di etichette

Integrazione DiffServ-MPLS DiffServ: modello per la fornitura di QoS IP MPLS: Tecnica di inoltro pacchetti MPLS Support for DiffServ: rfc 3270 DSCP nel pacchetto IP; LSR analizzano solo intestazione MPLS PHB deducibile da Campo Label Campo Exp TTL S Exp Label 8 1 3 20

Integrazione DiffServ-MPLS L-LSP Un LSP per ciascuna Classe di Servizio in una PHB scheduling class : Il PHB viene dedotto dal valore della Label (campo Exp per determinare livello priorita’ di scarto) E-LSP Un unico LSP per tutte le Classi di Servizio : Il PHB viene dedotto dal valore del campo Exp Nel caso in cui la rete supporti più di 8 PHBs, oppure nel caso in cui il trasporto dei pacchetti IP avviene utilizzando una tecnologia di livello 2 dove non sia possibile mappare il campo Exp (es. ATM), il metodo basato su E-LSP non va più bene. L’ovvia scelta alternativa è quella di utilizzare le labels per identificare il PHB corretto. In questo caso si parla di L-LSP. Prima di vedere il funzionamento del metodo L-LSP si ricorda una proprietà molto importante del gruppo di PHB Assured Forwarding. Questa dice che i pacchetti appartenenti a una stessa classe AF, (quindi che possibilmente differiscano solo per il livello di “drop precedence”), debbono essere inoltrati in sequenza verso il nodo successivo. Come risultato di questo vincolo, i pacchetti di una stessa classe AF vengono tipicamente posti nella stessa coda. Ora, alcuni LSR implementano una coda per ciascun LSP, e in alcuni casi due LSP verso la stessa destinazione potrebbero seguire percorsi diversi. Perciò, per soddisfare il vincolo della sequenzialità intra-classe del traffico AF, sarà necessario inviare pacchetti appartenenti alla stessa classe AF (es. pacchetti AF11, AF12 e AF13) sul medesi-mo LSP. Il gruppo di PHB AF è l’unico al momento con il vincolo della sequenzialità intra-classe; in futuro però nulla vieta che siano definiti altri. Per questo è stata introdotta una nuova definizione che è quella di PHB scheduling class, definita come un gruppo di PHB con il vincolo che pacchetti di diversi PHB siano inoltrati in sequenza. La regola fondamentale è allora che pacchetti appartenenti alla stessa PHB scheduling class debbono essere trasportati sul medesimo LSP. Una volta inviati i pacchetti di una stessa PHB scheduling class sul medesimo LSP, sorge il problema di come identificare il trattamento completo del pacchetto (es. il livello di “drop precedence”). A tale scopo si possono utilizzare tutti o parte dei bit del campo Exp, qualora questo sia disponibile, oppure altri accorgimenti, come nel caso di MPLS su ATM, dove è possibile usare il bit CLP dell’intestazione della cella ATM (che però permette due soli livelli di differenziazione). Nell’esempio riportato nella slide, sono definiti due L-LSP. Il primo trasporta traffico EF mentre il secondo trasporta pacchetti della classe AF1y. La differenziazione nel livello di “drop precedence” avviene attraverso i bit del campo Exp oppure, nel caso di MPLS su ATM, tramite il bit CLP.

Dominio DiffServ/MPLS E-LSP Campo “EXP” Dominio DiffServ/MPLS 1 L1 2 L1 PHB 1 PHB 2 . . .

E-LSP . . . . . . . . . . . . ILM Label NHLFE L1 Label: L2 Interfaccia: s0 Next Hop: p.to – p.to Tipo LSP: E-LSP Mappa EXPPHB . . . EXP PHB Best-Effort 1 AF11 . . . . . . . . . . . . La procedura di “Label Swapping” consiste in: esaminare l’etichetta alla sommità della pila (etichetta di livello più elevato); estrarre dalla ILM il NHLFE da utilizzare in corrispondenza del valore dell’etichetta; traslare il valore dell’etichetta secondo quanto scritto nel NHLFE; inoltrare il pacchetto sull’interfaccia e verso il Next-Hop scritti nel NHLFE. E’ bene tener presente che il valore del Next-Hop può essere diverso dal Next-Hop definito dal protocollo di routing IP. Ciò avviene ad esempio, nel caso di costruzione di percorsi “espliciti”.   EXP L1 s0

Dominio DiffServ/MPLS L-LSP Dominio DiffServ/MPLS Campo “EXP” 000 L1 001 L2 010 L2 In una rete che supporta al più 8 PHBs, il campo Exp è sufficiente per definire una corrispondenza tra DSCP e PHB; è necessario a tale scopo che ciascun LSR venga configurato con l’associazione ExpPHB. Si noti che non viene richiesta nessuna segnalazione aggiuntiva rispetto a quanto già visto nel capitolo su MPLS; le label indicano al LSR dove inoltrare il pacchetto e il campo Exp come trattarlo (PHB). Un LSP che viene definito sotto queste condizioni viene detto E-LSP, dove la “E” indica che il corrispondente PHB è dedotto direttamente dal campo Exp. Come esempio, si consideri una rete che supporti due Classi di Servizio: Best-Effort e Premium. Si potrebbero utilizzare rispettivamente i valori ‘000’ e ‘001’ del campo Exp per definire il trattamento dei pacchetti delle Classi Best-Effort e Premium. I LER e i LSR dovrebbero essere configurati in modo tale da fornire il trattamento di default (Best-Effort) ai pacchetti con il campo Exp ‘000’ e un trattamento preferenziale (esem-pio, EF PHB) ai pacchetti con il campo Exp ‘001’ . Si noti che la soluzione tramite E-LSP non richiede nessuna modifica dei protocolli di segnalazione MPLS (es. LDP) poiché tutte le Classi di Servizio utilizzano lo stesso LSP, che può essere scelto convenientemente tramite le tecniche convenzionali. EF AF13 Probabilità di Scarto 1 Lunghezza media della Coda AF12 L1: etichetta per l’L-LSP che supporta il PHB EF L2: etichetta per l’L-LSP che supporta la PSC AF1x

LSR DiffServ Informazioni aggiuntive nel Next Hop Label Forwarding Entry: Tipo di LSP (E-LSP; L-LSP) PHB supportati Corrispondenza tra l’informazione di classificazione nel pacchetto entrante e un PHB Modalità di codifica dell’informazione di classificazione nel pacchetto uscente

Background: Tunnel DiffServ DSCP=“x” DSCP tunnel=“y” DSCP=“x” x x y x D1 D1 D2 Tunnel DiffServ

LSP vs Tunnel DiffServ Un LSP ha caratteristiche analoghe ad un Tunnel: LSR intermedi al LSP lavorano solo sull’ elemento esterno dell’intestazione MPLS; l’informazione DiffServ del pacchetto non viene considerata LSP unidirezionali L’informazione DiffServ contenuta nell’elemento esterno dell’intestazione MPLS (EXP) puo’ essere variata dai router intermedi a causa di riclassificazione

LSP: modello PIPE D1 D3 Rete MPLS DSCP=“x” Intestazione MPLS DSCP=“x” PHB determinato sulla base del contenuto dell’elemento esterno dell’intestazione MPLS

LSP: modello short PIPE DSCP=“x” Intestazione MPLS DSCP=“x” x x L1 x x D1 D3 Rete MPLS LSP PHB determinato sulla base del contenuto del campo DSCP del pacchetto IP

Configurazione della QoS in una rete 1^ Definizione dei criteri di Classificazione Router(config)# class-map PIPPO Router(config-cmap)# match ... 2^ Colorazione del traffico in ingresso Router(config)# policy-map . . . Router(config-pmap)# class . . . Router(config-pmap-c)# set . . . 3^ Definizione delle politiche di QoS (PHB) Router(config)# policy-map . . . Router(config-pmap)# class . . . Router(config-pmap-c)#. . . La configurazione del protocollo LDP richiede essenzialmente due passi: abilitare LDP come protocollo di distribuzione delle etichette (Nota: ricordiamo che LDP potrebbe non essere l’unico protocollo di distribuzione delle etichette implementato nel router; questo perché l’architettura MPLS non prevede un unico protocollo e inoltre un costruttore potrebbe aver lasciato implementati dei protocolli proprietari); l’abilitazione può essere fatta interfaccia per interfaccia, oppure globalmente con un unico comando. Configurare il meccanismo di “discovery”, i parametri del protocollo, come ad esempio i “timer” (Keepalive, Hello Hold time, ecc.), modalità di distribuzione, identificativo del LSR, eventuali meccanismi di controllo della distribuzione delle asoociazioni, ecc. . Come sempre, alla fine è bene effettuare una verifica dei comandi implementati. 4^ Associazione dei PHB alle interfacce Router(config)# interface s0/0 Router(config-if)# service-policy input/output . . .

clients Esempio Cliente B ISP Cliente A P2 P1 P3 Web server PE2-1 Lo0: 192.168.0.21/32 Lo0: 192.168.0.22/32 Fa0/0 Fa0/0 .21 .22 ISP 172.16.2.0/24 FTP server OSPF Area 2 .2 Fa0/0 P2 Lo0: 192.168.1.2/32 s0/0 s0/1 .2 .2 EL1-1 OSPF Area 1 172.16.12.0/24 172.16.23.0/24 OSPF Area 3 EL3-1 Mail server .11 LSR P1: Hostname: P1 Indirizzi interfacce: Loopback0: 192.168.0.1 255.255.255.255 Ethernet0/0: 172.16.1.1 255.255.255.0 Serial0/0 : 172.16.12.1 255.255.255.0 Serial1: 172.16.13.1 255.255.255.0 LSR P2: Hostname: P2 Loopback0: 192.168.0.2 255.255.255.255 Ethernet0/0: 172.16.2.2 255.255.255.0 Serial0/0: 172.16.12.2 255.255.255.0 Serial0/1: 172.16.23.2 255.255.255.0 LSR P3: Hostname: P3 Loopback0: 192.168.0.3 255.255.255.255 Ethernet0/0: 172.16.3.3 255.255.255.0 Serial0/0: 172.16.13.3 255.255.255.0 Serial0/1: 172.16.23.3 255.255.255.0 Fa0/0 Fa0/0 .1 .31 .3 s0/1 Cliente A Lo0: 192.168.0.11/32 s0/0 Lo0: 192.168.0.31/32 172.16.1.0/24 Fa0/0 P1 s0/1 s0/0 P3 Fa0/0 172.16.3.0/24 172.16.13.0/24 PE1-2 .1 .1 .3 .3 PE3-2 .12 Lo0: 192.168.1.1/32 Lo0: 192.168.1.3/32 Fa0/0 OSPF Area 0 (Backbone) .32 Fa0/0 Lo0: 192.168.0.12/32 Lo0: 192.168.0.32/32

Classi di servizio REAL TIME: gestita con PQ, traffico in eccesso scartato GOLD:banda minima garantita 500kbit/s e limite scarto pacchetti=90 pacc SILVER: banda minima garantita 300kbit/s e limite scarto pacchetti=60 pacc BRONZE: banda minima garantita 150kbit/s e limite scarto pacchetti=30 pacc BEST EFFORT: banda minima garantita 50kbit/s e limite scarto pacchetti=10 pacc

Example Classificazione RT Controllo PQ, 500kb/s Traffico Controllo 1 RT Controllo Traffico PQ, 500kb/s Controllo Traffico WFQ; 500kb/s G G G Controllo Traffico WFQ; 300kb/s Scheduler S S S WFQ; 150kb/s B Controllo Traffico WFQ; 50kb/s

SLA Clente A - ISP Il traffico FTP puo’ essere immesso in rete alla velocità max di 16kbit/s con un burst max di 3kbytes; il traffico conforme va inserito in classe GOLG; quello non conforme in BEST EFFORT Il traffico WWW puo’ essere immesso in rete alla velocità max di 12kbit/s con un burst max di 2,5kbytes; il traffico conforme va inserito in classe SILVER; quello non conforme in BEST EFFORT Il resto del traffico puo’ essere immesso in rete allavelocità max di 8kbit/s con un burst max di 2kbytes; il traffico conforme va inserito in classe BRONZE; quello non conforme in BEST EFFORT

SLA Clente B - ISP Il traffico Real time deve avere priorita’ assoluta Il traffico FTP/WWW e SMTP controllato con token bucket con r=56 kbit/s, b=10kbytes; il traffico conforme va inserito in classe SILVER; quello non conforme in BEST EFFORT Il resto del traffico controllato con single rate TCMcon CIR=16 kbit/s; CBS=EBS=3kbytes; il traffico delle classi risultanti immesso in BRONZE; BEST EFFORT; scartato