Presentation is loading. Please wait.

Presentation is loading. Please wait.

G.8032 for Ethernet Networks Ethernet Ring Protection

Similar presentations

Presentation on theme: "G.8032 for Ethernet Networks Ethernet Ring Protection"— Presentation transcript:

1 G.8032 for Ethernet Networks Ethernet Ring Protection
Yaacov Weingarten Nokia Siemens Networks Title slide Used as a prompt to start the presentation Insert 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 efficiency Inter-connected rings Operator 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.8032 Recommendation was consented within working group in Feb 2008 Sent for Last Call comments during month of April Four companies submitted comments Technical comments were addressed during interim meeting, 30 Apr – all resolved to satisfaction of commenting companies Additional resolution (of editorials) within two weeks Begun work on next revision of the Recommendation. New revision will address: Multiple Instances Inter-connected ring topologies and protection Operator 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 rings Each ring is addressed separately in R-APS messages Using 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 ring When 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 link A 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 supported Interconnected rings may share more than one shared link A node that is common to different rings may be connected by more than one shared link A shared link may be shared by more than two rings ERP1 ERP2 ERP3 ERP1 ERP2 ERP3 ERP1 ERP2 ERP3

9 Interconnected Rings – Topology Limitations
ERP1 ERP2 ERP3 ERP4 Interconnected rings shall not form a ring of rings Two 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 node Ring A Ring B Shared node Non shared link Non shared link

10 Interconnected Rings – Priority-based protection
Nokia Siemens Networks proposes to assign a priority to each RPL, through configuration When 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 ring Updating node software Switching hardware – switch out/in of new nodes or links Periodic maintenance Support for commands to the ring – Manual Switch or Forced Switch Need to establish relative priority between commands and Signal Fault situations Switch mechanism and recovery Treat special cases – sequential requests, simultaneous requests General consensus reached at last interim meeting Forced Switch > higher than Signal Failure > higher than Manual Switch Simultaneous requests – Manual Switch cancel out, Forced Switch co-exist MAC 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.

12 Manual Switch behavior
RPL A B C D E F G Idle 1 Manual Switch 2 3 MS MS MS MS MS MS MS MS 4 Flush Flush Flush Flush Flush Manual Switch state 5 Flush Flush 6 Clear 7 NR NR NR NR NR NR NR NR 8 NR RB NR RB NR RB NR RB NR RB NR RB NR RB NR RB Flush Flush Flush Flush Flush Flush Flush Idle 9 NR RB NR RB NR RB NR RB NR RB NR RB NR RB NR RB

13 Thank You

Download ppt "G.8032 for Ethernet Networks Ethernet Ring Protection"

Similar presentations

Ads by Google