Presentation on theme: "G.8032 for Ethernet Networks Ethernet Ring Protection"— Presentation transcript:
1 G.8032 for Ethernet Networks Ethernet Ring Protection Yaacov WeingartenNokia Siemens NetworksTitle slideUsed as a prompt to start the presentationInsert footnotes as appropriate.Nokia Siemens Networks has four information confidentiality classes: Public, For internal use, Confidential, Secret "Public" - May be distributed to anyone. Usually public information shall be available for everyone. "For internal use" - May be distributed to anyone employed or having a business relationship with the company under a valid non-disclosure agreement. The disclosure of small amounts of this information to the public will not cause meaningful damages to the company. ‘’For internal use’’ is the default class for Nokia Siemens Networks information, this should be included e.g. in all MS Office (master) templates. (Previously Nokia: Company Confidential, Siemens: Internal use) "Confidential" - May be distributed only to people who have a valid business need. The validity of the business need can be judged by anyone who is authorised to possess the information. Unintentional disclosure of this information to the public will cause significant damages to the company. ‘’Confidential’’ is the default class for any customer information. (Previously Nokia and Siemens: Confidential) "Secret" - May be distributed only to people who are specifically authorised by the owner of the information. Disclosure of this information to the public will cause serious damages to the company. (Previously Nokia: Secret, Siemens: Strictly confidential) All documents in Nokia Siemens Networks shall be labelled according to this confidentiality schema.
2 Agenda Why Rings? Status of G.8032 Multiple instances – bandwidth efficiencyInter-connected ringsOperator commands
3 Why Rings?Considered the simplest redundant topologies and are often encountered in Metropolitan Ethernet Networks (Metro) to minimize optical fiber usage.Effective means of aggregating DSLAMs or small Ethernet switches in multi-tenant or multi-dwelling environments in Metro access networks
4 Status of G.8032Recommendation was consented within working group in Feb 2008Sent for Last Call comments during month of AprilFour companies submitted commentsTechnical comments were addressed during interim meeting, 30 Apr – all resolved to satisfaction of commenting companiesAdditional resolution (of editorials) within two weeksBegun work on next revision of the Recommendation. New revision will address:Multiple InstancesInter-connected ring topologies and protectionOperator commands – e.g. Manual switch, Forced switch
5 Multiple Instances – bandwidth efficiency Ability to configure different logical rings that are protected, each with its own RPL (and RPL Owner).Allows greater utilization of all the links in the ring, possibly in different logical ringsEach ring is addressed separately in R-APS messagesUsing VID or different MAC address (in SA)
6 Interconnected Rings – General Objectives Only “reasonable” carrier topologies (that would be configured in actual operator/service provider domains) should be addressed.The rules defining the Interconnected ring topologies supported are expressed in following slides.Ring interconnection should not require changes to the single ring protection mechanism.Although there may be a need to add features to the APS protocol, the basic messages and interactions should not be affected.Nodes that are not at the ends of shared links should not need special provisioning to support shared links in the ringWhen a shared link fails, it is necessary to prevent the formation of a super loop, as may be the case if both rings protect at the same time.
7 Interconnected Rings – General Guidelines Shared link may act as the RPL for only one of the rings that share the linkA signal failure on a non-shared link (when the ring is in idle state) should only trigger protection switching within the ring where the link failed, the other interconnected rings should be agnostic to this event
8 Interconnected Rings – Topology rules General consensus at ITU discussions to set principles of interconnected ring topologies that will be supportedInterconnected rings may share more than one shared linkA node that is common to different rings may be connected by more than one shared linkA shared link may be shared by more than two ringsERP1ERP2ERP3ERP1ERP2ERP3ERP1ERP2ERP3
9 Interconnected Rings – Topology Limitations ERP1ERP2ERP3ERP4Interconnected rings shall not form a ring of ringsTwo rings shall not be connected by two shared nodes if the link between these nodes is not shared (when two links exist between the two shared nodes)Two rings shall not be connected by any two shared links if these links are not connected to the same shared nodeRing ARing BShared nodeNon shared linkNon shared link
10 Interconnected Rings – Priority-based protection Nokia Siemens Networks proposes to assign a priority to each RPL, through configurationWhen Shared link fails – only RPL with highest priority protects ring, thereby preventing formation of super loop
11 Operator commands – Manual/Forced Switch Operator has need to intervene into current flow control of the ringUpdating node softwareSwitching hardware – switch out/in of new nodes or linksPeriodic maintenanceSupport for commands to the ring – Manual Switch or Forced SwitchNeed to establish relative priority between commands and Signal Fault situationsSwitch mechanism and recoveryTreat special cases – sequential requests, simultaneous requestsGeneral consensus reached at last interim meetingForced Switch > higher than Signal Failure > higher than Manual SwitchSimultaneous requests – Manual Switch cancel out, Forced Switch co-existMAC learning process to build the MAC forwarding table of the Ethernet switches.For an incoming frame, one of the following decision is taken (based on the destination MAC address):Forward via another port to reach the known destination.Filter (i.e. drop) when the station requested is attached to the same port.Flood unknown frames.