g.8032 : ethernet ring protection characteristics, architectures and the ring aps protocol

G.8032 : Ethernet Ring protectioncharacteristics, architectures

and the Ring APS protocol

Satoshi NARIKAWANTT

(G.8032 Acting Co-editor)

Joint ITU-T/IEEE Workshop on The Future of Ethernet Transport

(Geneva, 28 May 2010)

Geneva, 28 May 2010

Outline

Objectives and PrinciplesBasic protection mechanismRevision notesDetailed functionalityFuture workSummary

Geneva, 28 May 2010 2

Outline



Objectives and Principles

Protection switching on Ethernet layerUse of Ethernet OAM frames called R-APS message for protection behavior Preventing any loops by blocking mechanismVLAN based protection switchingSub-50msec protection switchingSupport of administrative commands

A B

E D

F C

A B

E D

F C

A B

E D

F C


Outline



Basicprotection mechanism

Normal conditionBlock RPL (Ring Protection Link)

Failure conditionBlock failed linkSend R-APS messagesUnblock RPLPerform FDB flush on all ring node as needed

A B

E D

F C

A B

E D

F C

A B

E D

F C

R-APS(SF)

R-APS(SF)


Outline



G.8032 (06/2008)

Revision approved in June 2008Supported Features

Single ring protectionRevertive behaviorState based flush logic

Ring


G.8032 (04/2009)

Amendment approved in April 2009Supported Features

Multi-ring protection with R-APS Virtual ChannelRevertive behaviorState based flush logicFlush propagation

Major Major

Sub SubSub

Major


G.8032 (03/2010)

Revision approved in March 2010 Supported Features

Multi-ring protection with/without R-APS Virtual ChannelRevertive/non-revertive behaviorFlush logic with Node-ID and BPR (Blocked Port Reference) mechanismAdministrative commands (Manual/Forced switch, Clear)Ability to block RPL at both ends of linkMultiple (logical) ERP Instances over a given physical ring

Major Major

Sub SubSub

Major Major

Sub

Sub


Outline



Interconnected Rings

G.8032 supports for a network of interconnected rings based on the following terminology.

Interconnection Nodeconnects between Ethernet rings

Major Ringconstitutes a closed ringis controlled by its own ERP instance with its own RPL

Sub-Ringis connected to a Major Ring or upper Sub-Ring via the Interconnection Nodes and does not constitute a closed ringis controlled by its own ERP instance with its own RPL

Major

Major

Major

Major

Sub Sub

Sub

Major

Sub

Sub

Sub


R-APS Virtual Channel

The 2010 version supports two implementation options for R-APS control channel of the Sub-Ring.

with R-APS Virtual Channelwithout R-APS Virtual Channel

In the first option, R-APS messages are encapsulated and transmitted over an R-APS Virtual Channel configured on the Major Ring.In the second option, R-APS messages are terminated at the Interconnection Nodes but not blocked at RPL of the Sub-Ring.

Major

Sub Sub

Major

R-APS Channelof Major Ring

R-APS Channelof Sub-Ringwith R-APS

Virtual Channel

Sub

Major

R-APS Channelof Sub-Ring

without R-APSVirtual Channel

Major

Sub

Physical Ring

R-APS Virtual Channel

R-APSChannel


Administrative commands

New revision supports basic operator administrative commands

Forced Switch (FS) – allows operator to block a particular ring port

Effective even if there is existing SF conditionMultiple FS commands supported per ringMay be used to allow immediate maintenance operations

Manual Switch (MS) – allows operator to block a particular ring port

Not effective if existing FS or SF conditionOverridden by new FS and SF conditionsNew MS commands are ignored

Clear – cancels an existing FS/MS command on the ring port

May be used (at RPL Owner Node) to trigger reversion


Multiple ERP instances

New revision supports multiple ERP instancesERP instance is composed of a set of VLANs.Multiple ERP instances can be configured on a same physical ring.ERP instance protects a subset of the VLANs that transport traffic over the physical ring.Each ERP instance is independent of other ring instances.

Instance 1

Instance 2


R-APS message

R-APS message format (based on Y.1731 APS)

Status ReservedBPR

DNF

RB

Node ID (6 octets)StatusSub-code

Node ID9

Reserved 2 (24 octets)13

……

End TLV (0)last

[optional TLV starts here; otherwise End TLV]37

Request/State

5

TLV Offset (32)Flags (0)OpCode (R-APS = 40)Version (1)MEL1

12345678123456781234567812345678

4321

Status ReservedBPR

DNF

RB

Node ID (6 octets)StatusSub-code

Node ID9

Reserved 2 (24 octets)13

……

End TLV (0)last

[optional TLV starts here; otherwise End TLV]37

Request/State

5

TLV Offset (32)Flags (0)OpCode (R-APS = 40)Version (1)MEL1

12345678123456781234567812345678

4321


Outline



Future work item 1

End-to-end service resiliencyResilient metro/core network can be realized by G.8032v2, but access network is not yet supported by ring protection. Guidelines for providing end-to-end resilient service are under study.

G.8032

Dual node interconnection

Access network

Access network


Future work item 2

Multiple failure recoveryIn some cases, ring segmentation occurs due to multiple failures. Guidelines for a mechanism to minimize its effect are under study.

Major

Sub

Major

Sub

Major

Sub

Major

Sub

The 2010 version

under study

Normal condition Single failure condition Double failure condition Moving blocked link


Other future work items

Reduced consumption of VIDsMethod to reduce the number of VIDs allocated for R-APS control channel

FDB Flush optimizationMethod to minimize the effect of flooding in case of protection switching or reversion


Outline



Summary

G.8032 provides resilient Ethernet network by using ring architecture.The 2010 version supports multi-ring protection switching with functionality such as:

Revertive/non-revertive modeAdministrative commandsMultiple ERP instancesetc…

Some additional topics are under study including:End-to-end service resiliencyMultiple failure recoveryetc…


Thank you

g.8032 : ethernet ring protection characteristics, architectures and the ring aps protocol

Documents