Gestione del traffico su reti Metro Ethternet

Gestione del traffico su reti Metro Ethternet
Ethernet Bridging Gestione del traffico su reti Metro Ethternet

Sommario Riepilogo Carrier Ethernet Riepilogo Spanning Tree Protocol
Problemi con STP in reti MAN Soluzioni proposte: SPB Calcolo dei path Forwarding Altra soluzione :TRILL

Perché ethernet nelle MAN?!
<10 € 0 costi gestione per broadcast on unknown Quali problemi fa sorgere plug and play? Broadcast on unknown = tecnologia plug-and-play

Riassunto: Metro Ethernet I

Riassunto: Metro Ethernet II
IEEE ah IEEE 802.1d

Gestione Continuity Check messages = "heart beat" messages.
Detect connectivity failures in an MA. CCMs are multicast messages and they are confined to a domain Link Trace messages = track the path (hop-by-hop) Directly to the Originating MEP, and regenerates the Trace route Message Loop-back messages = determine the location of a fault Administratively initiated and stopped ITU-T Y.1731 additionally supports the following: Loss Measurement One way Delay Two way Delay Continuity Check messages = "heart beat" messages. Detect connectivity failures in an MA. CCMs are multicast messages. CCMs are confined to a domain (MD and unidirectional and do not solicit a response. Link Trace messages = track the path (hop-by-hop) to a destination MEP Similar in concept to User Datagram Protocol (UDP) Trace Route. Each receiving MEP sends a Trace route Reply directly to the Originating MEP, and regenerates the Trace route Message Loop-back messages = determine the location of a fault. Sending a high volume of LBM can test bandwidth, reliability, or jitter of a service, which is similar to flood ping. A MEP can send a Loopback to any MEP or MIP in the service. Unlike CCMs, Loop back messages are administratively initiated and stopped

Spanning Tree Protocol
È necessaria una topologia fisica ridondante (supporto fault), ma è necessario che quella attiva sia loop-free (broadcast on unknown) Soluzione: disattivazione di alcuni link Scelgo la root in maniera casuale (ID più basso) ed ogni bridge si calcola il percorso più breve per raggiungerla. IEEE D

Problemi con STP in reti MAN
In caso di fault devo ricostruire le forwarding table, quindi molti broadcast Non utilizzo percorso ottimo Non utilizzo tutta la banda che ho messo in campo Anche con RSTP (IEEE 802.1W) tempo di convergenza troppo alto Non posso gestire in maniera semplice il traffico

Perché ho bisogno di gestire il traffico?
Affidabilità Controllo della banda per servizio Rispetto Service Level Agreement (SLA)

PBB-TE traffic engineering

SPB shortest path bridging
IEEE ad (SPBM in ambito PBB) Calcolo di più path all’interno della rete Shortest path bridging MAC operation uses MAC addresses to identify the SPT 24 bits of the 802.1ah header service instance (I-SID) provide highly scalable support for service virtualization

SPB concept SPT Region SPVID = 22 Base VID 22 SPVID = 45 SPVID = 66
DA SA Payload 45 22 41 CST IST SPVID = 71 SPVID = 66 SPVID = 44 SPVID = 22 Base VID 22 Mantengo più topologie attive Voglio decidere sia dove andrà il mio pacchetto, sia che strada farà: associo BVID a ESP

SPB operation Shortest path between any two points is both the same and symmetrical for unicast and multicast IS-IS IS-IS BEB Backbone Edge Bridge BEB IS-IS IS-IS IS-IS IS-IS IS-IS Backbone Core Bridge BCB BCB BCB BEB BEB “A” PBBN IS-IS IS-IS BEB BEB

All pairs shortest path computation performed in parallel
SPB path da/per A Shortest path between any two points is both the same and symmetrical for unicast and multicast IS-IS IS-IS BEB Backbone Edge Bridge BEB IS-IS IS-IS IS-IS IS-IS IS-IS Backbone Core Bridge BCB BCB BCB BEB BEB “A” PBBN IS-IS All pairs shortest path computation performed in parallel IS-IS BEB BEB

I-SIDs define efficient subsets
SPBB Multicast Groups I-SID 5 I-SID 5 IS-IS IS-IS MMAC for 5 from A BEB Backbone Edge Bridge BEB IS-IS IS-IS IS-IS IS-IS IS-IS Backbone Core Bridge BCB BCB BCB BEB BEB “A” PBBN Posso calcolare degli alberi che non tocchino tutti gli edge per fare il multicast IS-IS I-SID 5 IS-IS BEB BEB I-SIDs define efficient subsets

Soluzione iniziale: MSTP
Come calcolo questi percorsi? Prima proposta MSTP Quali vantaggi ha? Poniamo il caso di avere root in ogni edge… Non mi devo neanche preocc del count to infinity! Con poche modifiche posso gestire i percorsi e uso path ottimi È più efficiente secondo studi recenti specie su topologie mesh Però non è nello standard!

Perché è stato scelto IS-IS?
Network loop prevention requires synchronizing state at island/core boundaries with bridges that only understand RSTP/MSTP BPDUs That means: using ISIS-SPB results in BPDUs injecting BPDU information into ISIS-SPB ISIS-SPB can make some decisions faster, e.g. determine CIST Port Roles and priority vectors Stop existing mechanisms from overriding with temporarily incorrect information Ports inside SPT Regions synchronize forwarding state with boundary ports Need to specify how, without reinvention Have to interoperate with existing bridges, and deploy in islands/network cores

Perché è stato scelto IS-IS?

IS-IS IS-IS is the Intermediate System to Intermediate System intra-domain routing protocol Usato per il calcolo dei path all’interno della rete Disegnato originariamente per OSI routing Facilmente estensibile

Punti di contatto IS-IS e OSPF
Link state protocols Hello packets per trovare e mantenere le adiacenze Dijkstra / SPF algorithm Visione gerarchica della topologia della rete Costo è metrica di default

Differenze tra IS-IS e OSPF
ISIS Link State Packets contengono TLVs, mentre OSPF Link State Updates contengono Link State Advertisements (LSAs) Per questo IS-IS può essere usato su Ethernet: estendo le funzionalità aggiungendo TLVs per portare informazioni riguardanti le VLAN, la mappatura VID, gli indirizzi multicast, gli identificativi CIST, la service group membership…

ISIS -SPB Uses the standard ISIS procedures to construct and update the link state database in each SPT bridge Disable B-MAC learning inside the backbone, only “border” learning Sets up and maintains at least one SPT for each bridge, which connects to every other bridge in an SPT region Support multiple path with same cost

ISIS -SPB SPTs have to meet two congruency criteria.
Forward and reverse paths must be the same between any two bridge pairs Unicast and multicast paths also have to be congruent For learning sake!

ISIS -SPB Can raise temporary loop Loop mitigation: ingress filtering
Loop avoidance: discard until neighbor topology match Failure detection è praticamente istantanea. Comunicazione della nuova topologia non è istantanea, ma si propaga. Ingress filtering mitigates loops by auditing the port of arrival of a frame, to ensure that it arrives on the port lying on the path from the source SPT. Neighbor bridges exchange digests of the topology database to check whether they have the same view of the physical topology, and by inference also have agreement on the distance to all SPT roots. An SPT bridge only installs changes to multicast forwarding to a peer when their digests match.

SPB Computation – Classic Method
For every node in the network do: Compute SPT: run Dijkstra for the node (the root of the spanning tree) Prune paths: keep only the shortest paths that go through the node performing the computation I-SID computation: compute the intersection of the set of I-SIDs for which the root node transmits with the set of I-SIDs for which the paths’ endpoints receive Pluses: Minuses: Simple, elegant, and quite efficient when most paths are not pruned Most of the paths computed by some nodes, most notably edge nodes, end up being pruned (because they are not offering transit) Best possible worst-case performance For these nodes, the SPB computation can be very expensive relative to the amount of forwarding state produced Failure detection è praticamente istantanea. Comunicazione della nuova topologia non è istantanea, ma si propaga. Ingress filtering mitigates loops by auditing the port of arrival of a frame, to ensure that it arrives on the port lying on the path from the source SPT. Neighbor bridges exchange digests of the topology database to check whether they have the same view of the physical topology, and by inference also have agreement on the distance to all SPT roots. An SPT bridge only installs changes to multicast forwarding to a peer when their digests match.

Faccio un esempio prendendo in considerazione l’uso parallelo di path isocosto. Per semplicità il mio esempio è su un pacchetto unicast con destinazione conosciuta. Il learning dei B-MAC è disabilitato. Un edge bridge (ad esempio l’1) ha un encapsulation database che mette in relazione DA-MAC /DA-BMAC/PATHID e S-VID con ISID, e una lista di SPT(PATHIDs) data dall’IS-ISspb associata ad ogni altro edge bridge possibile destinazione. Se il multipathing su path isocosto è disabilitato incapsula il frame in ingresso con il suo SA-BMAC, il DA-BMAC di destinazione e con l’ISID corrispondente al servizio (S-VID) e al path di cui sopra. Se il multipathing è abilitato, allora l’amministratore mi ha anche detto che il traffico associato ad un determinato servizio (S-VID) a quale SPT (PATHID), diverso da quello di default, va assegnato, e gli appiccicherà l’ISID opportuno. Un bridge core (ad es il 4), ha dei forwarding database che mettono in relazione DA-BMAC, ISID e porta(lista di porte per multicast) di forward, e gli sono imposti dal IS-ISspb. quando riceve un frame guarda il BMAC di destinazione, nell’esempio il 20. Questa destinazione lui ce l’ha di default sulla porta del link di sopra (ipotizzo io). Se viceversa è abilitato il multipathing, vedrà il 20 anche sull’altra porta, per cui guarda l’ISID che identifica il servizio e in base a quello decide su che porta mandarlo. In caso di multi cast ci sono dei DA-BMAC che non vengono né imparati, né distribuiti dall’IS-ISspb, ma ogni bridge se li calcola all’occorrenza sulla base del SA-BMAC. Se voglio fare un multi cast a partire dall’edge 1 a dei client che stanno dietro agli edge 19, 20 e 30 sempre della figura assegnerò a questo servizio un ISID, ad esempio 33, per il quale IS-ISspb costruirà tra gli altri un SPT rooted sull’1 che tocca esattamente 19, 20, 30. Allora l’1 alla ricezione di un frame di questo multi cast (se ne accorge perché ha DMAC C e un certo S-VID), gli schiaffa ISID 33 e si calcola il DA-BMAC che dovrebbe essere tipo "1.33" in questo caso (concateno ID source con PATHID). I bridge core vedendo quel DA-BMAC assegneranno i frame al SPT incentrato su 1, mandandolo a tutte le porte necessarie. Gli edge terminali, cioè 19, 20, 30 non devono scartare il frame, ma riconosceranno che quel DA-BMAC è in realtà un multi cast dall’1 ed è associato a loro perché hanno registrato il servizio 33 da IS-ISspb (verificano che dal SA-BMAC e dall’ISID si possa ricavare il DA-BMAC). Dis-incapsuleranno e inoltreranno sulle porte designate. In questo modo combino le decisioni di forwarding sia in base alla destinazione che in base al servizio. Nel paragrafo Support for MEF Services è spiegato come si associano gli ISID ai servizi di E-LINE, E-TREE, E-LAN. Notare bene che il processo di cui sopra non influisce sulle C-VLAN, per cui resta la separazione del traffico per client.

Multipathing Unicast Paths list DA-MAC DA-BMAC PATHID S-VID ISID

Multipathing Multicast Paths list DA-MAC DA-BMAC PATHID S-VID ISID

TRILL Transparent Interconnection of Lots of Links Simile all’SPB, ma
Standardizzato da IETF Ottimizzato per ambiente Data Center Non compatibile con architettura reti PBB Gestione dei loop temporanei con TTL

TRILL Gestione e troubleshooting più complicati

Sara Lago IPI Lab s.lago@cipi.unige.it

Gestione del traffico su reti Metro Ethternet

Presentazioni simili

Presentazione sul tema: "Gestione del traffico su reti Metro Ethternet"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back

Entrare

Autorizzarsi attraverso i social network:

Gestione del traffico su reti Metro Ethternet

Presentazioni simili

Presentazione sul tema: "Gestione del traffico su reti Metro Ethternet"— Transcript della presentazione:

Presentazioni simili

Sul progetto

Feed-back