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