The fundamentals of Ethernet!

Transcription

1 Building Ethernet Connectivity Services for Provider Networks" " Eduard Bonada i Cruells" Tesi Doctoral UPF / 2012 Dirigida per Dra. Dolors Sala i Batlle Departament de Tecnologies de la Informació i les Comunicacions Ethernet Bridging Overview The fundamentals of Ethernet Ethernet is broadcast Ethernet plug-n-play Ethernet needs the spanning tree protocol 1 1

2 Ethernet Bridging Overview Ethernet is broadcast In the original Ethernet all nodes are connected to the bus" Ethernet bridges interconnect different shared segments or point-to-point connections The broadcast service is maintained in all evolutions 2 Ethernet Bridging Overview Ethernet is Plug-n-play Ethernet bridges are plug-n-play: no configuration is needed to run Frames are flooded if the destination is unknown Forwarding tables are populated learning the paths from the received frames tracing back the origin s to d d to s learn DEST" PORT" s p1 forward DEST" PORT" s p1 Paths must be symmetrical (Só D) 3 2

3 Ethernet Bridging Overview Loop avoidance and the spanning tree Flooding frames to unknown destinations results into Broadcast storms It only works on loop-free topologies The Spanning Tree Protocol (STP) constructs a logical tree on top of any physical topology Ony tree links are active Broadcast is controlled and symmetrical paths are guaranteed 4 Motivation and problem definition Ethernet Extension to Provider Networks Network Providers are considering the use of Ethernet technology in their deployments Ethernet is positioned as a good candidate Ubiquity Bandwidth flexibility Reduced cost Challenges in the provider environment Scalability (geographical and operational) Resiliency (50ms) QoS (SLA), Management (OAM) 5 3

4 Motivation and problem definition The spanning tree is a key element The spanning tree is the architecture element that determines the network connectivity" It constructs a single shortest-path tree RSTP is the current technique specified in the IEEE standard Implications of using RSTP to construct the tree Cannot use redundancy because only tree links are active Sub-optimal paths are deployed, only Root sees shortest paths Long recovery times as RSTP suffers count-to-infinity when the Root fails 6 Motivation and problem definition Problem, approach and contributions Allows for quick recoveries in all failure situations We propose a complete solution that: " Makes use of available redundancy" Provides optimal paths between all pairs Approach based on understanding RSTP limitations and design required extensions" RSTP Characterization to understand the propagation model and countto-infinity RSTP-Conf to resolve the long recovery problems in the scenarios with count-toinfinity Thesis contributions" RSTP-SP to operate with optimal communication paths. Implementation of the protocol modules in the ns3 network simulator 7 4

5 Outline Motivation State of the Art RSTP description Analysis if the RSTP Behavior RSTP-Conf: avoiding count-to-infinity in RSTP RSTP-SP: shortest path extension to RSTP Conclusion 8 Outline Motivation State of the Art" RSTP description Analysis if the RSTP Behavior RSTP-Conf: avoiding count-to-infinity in RSTP RSTP-SP: shortest path extension to RSTP Conclusion 9 5

6 State of the art Viking Uses MSTP as a multiple tree framework Initially configures primary and backup trees The trees are externally computed by a central manager and configured into the MSTP instances of the bridges by SNMP" Failures are notified to the central manager that locally reconfigures the trees and remotely updates the MSTP Better use of redundancy Significant overhead Recovery time of 400ms Not plug-n-play 10 State of the art LSOM Substitutes the spanning tree by a link-state protocol The routing protocol initially configures the forwarding tables with point-to-point paths between bridges (bridge-bridge table) Bridges disseminate their connected end-hosts to the rest of nodes Better use of redundancy Better path optimality Not backwards-compatible Not plug-n-play 11 6

7 State of the art IEEE 802.1aq Shortest Path Bridging Last evolution currently discussed in IEEE Work in parallel with this thesis Configures one tree per node to deploy optimal paths Substitutes the STP with a link-state protocol Directly compares to RSTP-SP 12 Outline Motivation State of the Art RSTP description" Analysis if the RSTP Behavior RSTP-Conf: avoiding count-to-infinity in RSTP RSTP-SP: shortest path extension to RSTP Conclusion 13 7

8 RSTP description Distributed configuration of the tree RSTP constructs the tree by activating or blocking bridge ports" Each bridge selects the state of its own ports RSTP is a distance-vector protocol Each node selects its best path to the Root to construct the branches 14 RSTP description Stored information: Port roles The port state is determined by the Role of each port Root role: The active port that connects the bridge up to the Root Designated role: The active port(s) that connect the bridge down to the leaves Alternate role: The inactive port(s) that provide an extra connection to the Root, but temporarily blocked. UPF - July 16 th 2012 Building Ethernet Connectivity Services for Provider Networks 15 8

9 RSTP description Stored information: Priority vectors Port roles are selected comparing topological information of different bridges This topological information is exchanged as Priority Vectors (PV) BPDU messages contain the exchanged PV The PV fields are sequentially compared and a lower value indicates a better vector that updates Priority Vector Root ID of the Root Cost Cost to it Bridge ID of the Bridge Port Port of the Bridge UPF - July 16 th 2012 Building Ethernet Connectivity Services for Provider Networks 16 RSTP description All bridges initialized as Root At start-up all bridges believe they are the Root Transient configuration as there should be a single Root A bridge B disseminates its own vector [B:0:B:0] indicating that B is the Root and that B is at distance 0 from the Root (itself) [0:0:0:p] [6:0:6:p] 17 9

10 RSTP description Processing of a received BPDU The priority vector comparison determines the operation An equal or worse vector does not update A better vector updates, reconfigures and disseminates A vector from the parent always updates equal - BPDU received Compare vectors received is better (or from parent) Configure Tree Store Select port roles Select port states Disseminate BPDUs worse Reply BPDU Continuous sequence of updating vectors makes the algorithm evolve 18 RSTP description Reception and dissemination of BPDUs The better vectors update and disseminate [0:0:0:1] [0:1:4:1] Received from B0 Stored in B4 [0:0:0:1] compare [4:0:4:0] [0:0:0:1] update [0:1:4:0] disseminate [0:1:4:p] All nodes keep updating its vectors until the best possible vector is received, which represents the best possible path to the Root 19 10

11 Outline Motivation State of the Art RSTP description Analysis of the RSTP Behavior" Nature of the tree construction" Root failure and count-to-infinity RSTP-Conf: avoiding count-to-infinity in RSTP RSTP-SP: shortest path extension to RSTP Conclusion 20 Nature of the tree construction Wave-fronts propagation The propagation of BPDUs can be modeled as wave-fronts of information that start propagating at each node. When two wave-fronts encounter, the one about a higher Root wins and removes the other. Only the wave-front starting at B0 always wins and hence it spans the entire network

12 Nature of the tree construction Theoretical bound of the convergence time Theoretical bound of the convergence time CT = max(l br ) x t hop The feasibility of this bound depends on the ability to detect that root messages have fully propagated through the entire network Original STP is based on timers RSTP introduces the proposal/agreement handshake 22 Nature of the tree construction Cold-start evaluation: Convergence Time (CT) Ring topology of increasing connectivity 100 executions, random BridgeIDs 1 hop = 1.33 msec Higher size, higher CT Higher redundancy, lower CT 23 12

13 [0:6] 7/15/12 Outline Motivation State of the Art RSTP description Analysis of the RSTP Behavior" Nature of the tree construction Root failure and count-to-infinity" RSTP-Conf: avoiding count-to-infinity in RSTP RSTP-SP: shortest path extension to RSTP Conclusion 24 Root failure and count-to-infinity Root failure and count-to-infinity in RSTP RSTP suffers count-to-infinity only in the scenarios where the Root fails" BPDUs about the failed Root start looping and are only removed when the BPDU hop counter reaches its maximum value [0:7] [0:5] MessAge: 20 Delays the recovery because first needs to remove the looping BPDUs The count-to-infinity is caused because information about the failed Root stored in alternate ports is disseminated 25 13

14 Root failure and count-to-infinity Appearance of a virtual Root The looping BPDUs result into a complex scenario if several physical loops exist The crossing of BPDUs with particular vectors results into the selection of two root ports at both sides of the link This creates a stable virtual Root between the two root ports The two root ports are in a deadlock because they wait for the virtual Root to send refreshing BPDUs They trigger a reconfiguration after 3 not-received BPDUs (6 seconds) Each deadlock represents a temporary stop of the count-to-infinity 26 Root failure and count-to-infinity RSTP in Root failure scenarios: Recovery Time (RT) Ring-based topologies 100 executions, random BridgeIds, B0 fails MaxAge = N 27 14

15 Outline Motivation State of the Art RSTP description Analysis if the RSTP Behavior RSTP-Conf: avoiding count-to-infinity in RSTP" RSTP-SP: shortest path extension to RSTP Conclusion 28 RSTP-Conf: avoiding count-to-infinity in RSTP RSTP-Conf: a confirmation technique The cause of the count-to-infinity is the use of information in alternate ports RSTP-Conf avoids count-to-infinity introducing a confirmation before using vectors in alternate ports The mechanism is triggered when a Root neighbor detects a failure on its Root port The neighbor floods a request asking whether the Root is alive The neighbor only reconfigures the tree after receiving the confirmation that the Root is still alive Request ( rd ) Confirmation ( ra ) UPF - July 16 th 2012 Building Ethernet Connectivity Services for Provider Networks 29 15

16 RSTP-Conf: avoiding count-to-infinity in RSTP Tree reboot after a Root failure recovery If the Root fails, all neighbors send requests All nodes receive the requests, arise as Root and select the new tree Request from B4 Request from B2 Request from B3 Common BPDUs Global tree reboot that takes one round-trip at most UPF - July 16 th 2012 Building Ethernet Connectivity Services for Provider Networks 30 RSTP-Conf: avoiding count-to-infinity in RSTP RSTP-Conf in Root failure scenarios: Recovery Time (RT) Ring-based topologies 100 executions, random BridgeIds, B0 fails 1 hop = 1.33 msec Higher size, higher CT cold start Higher redundancy, lower CT 31 16

17 Outline Motivation State of the Art RSTP description Analysis if the RSTP Behavior RSTP-Conf: avoiding count-to-infinity in RSTP RSTP-SP: shortest path extension to RSTP" Conclusion 32 RSTP-SP: shortest path extensions to RSTP RSTP-SP: a shortest path extension RSTP-SP addresses all requirements: shortest paths, use of redundancy and recovery time How? One tree rooted at each node Optionally introduce RSTP-Conf (Count-to-infinity is not that harmful) Design challenges N trees configured by N protocol instances Ensure symmetrical paths UPF - July 16 th 2012 Building Ethernet Connectivity Services for Provider Networks 33 17

18 RSTP-SP: shortest path extensions to RSTP N trees configured by N protocol instances Independent single tree instances running in parallel Per-tree variables Per-tree event processing UPF - July 16 th 2012 Building Ethernet Connectivity Services for Provider Networks 34 RSTP-SP: shortest path extensions to RSTP Selection of not symmetrical paths In the multiple tree scenario: The path S=>D is through tree T2 (B6 selects B1 as parent) The path D=>S is through tree T6 (B2 selects B0 as parent) The unidirectional paths are not symmetrical The priority vector comparison uses local information (neighbor identifier) and hence takes different decisions at different sides of the path UPF - July 16 th 2012 Building Ethernet Connectivity Services for Provider Networks 35 18

19 RSTP-SP: shortest path extensions to RSTP Guaranteeing path symmetry The path-array is composed of all the traversed IDs The array is sorted; the elements are sequentially compared; a lower element wins. B6" B B B2" B B UPF - July 16 th 2012 B The unidirectional paths are symmetrical because global information is used to select the paths Building Ethernet Connectivity Services for Provider Networks 36 RSTP-SP: shortest path extensions to RSTP Extension to incorporate the path-array The path-array is introduced in the priority vectors The comparison of vectors is updated considering the path-array instead of the Bridge field Priority Vector Root ID of the Root Cost Cost to it Path-Array IDs of the Bridges Building the path-array Port is Port of the Bridge straightforward because the BPDUs propagate from the Root of each tree BPDUs keep track of the visited bridges UPF - July 16 th 2012 Building Ethernet Connectivity Services for Provider Networks 37 19

20 RSTP-SP: shortest path extensions to RSTP RSTP-SP evaluation: Convergence Time (CT) Grid of degree 4, 64 nodes, 100 executions with random BridgeIDs RSTP RSTP-SP RSTP-SP-Conf SPB RSTP-SP RSTP-SP-Conf SPB Time from startup/failure until last port is set to Forwarding Traffic received during recovery from a central link failure Recoveries in RSTP-SP almost do not affect data reception 38 RSTP-SP: shortest path extensions to RSTP RSTP-SP evaluation: Message Overhead (MO) Amount of BPDUs transmitted to construct or recover the trees RSTP RSTP-SP RSTP-SP-Conf SPB Amount of BPDUs transmitted RSTP-SP requires a higher message overhead during recoveries 39 20

21 Outline Motivation and problem definition State of the Art RSTP description Analysis if the RSTP Behavior RSTP-Conf: avoiding count-to-infinity in RSTP RSTP-SP: shortest path extension to RSTP Conclusion" 40 Conclusion and open issues Conclusion Global solution that (1) provides quick recovery, (2) uses available redundancy, and (3) operates with optimal paths Characterization of RSTP Initial tree construction modeled as wave-fronts propagation Identification of causes and consequences of count-to-infinity Design and evaluation of RSTP-Conf Introduces delay in failure recoveries Recovers from Root failure in one round-trip at most Design and evaluation of RSTP-SP Deploys optimal paths and makes use of redundancy Compared to SPB: better CT worse MO 41 21

22 Conclusion and open issues Open issues and future guidelines Extend analysis Computational analysis to dimension nodes and feasibility of a real implementation Enhance performance Reduce message overhead in RSTP-SP by sharing information among different tree instances Extend functionalities Different comparison rules for path-arrays Use of the path-array to provide path control 42 Thank you for your attention" " " Questions?" " 22