1. Some aspects to be determined in PIRC July 2007 802
Some aspects to be determined in PIRC July Plenary Meeting San Francisco, U.S. Huawei Technologies
11/07/2007
IEEE RPRWG

2. Status message
Status message is respectively transmitted periodically by two inter-ring nodes of a protection group to notify the status the to opposite inter-ring node.
Only inter-ring nodes process the status message
New controlType
Broadcast address or new multicast address
Appropriate transmission interval
11/07/2007
IEEE RPRWG

3. Status message function
Status message notifies the local inter-ring node’s status to the opposite inter-ring node.
Active: Notify status change of the local inter-ring node to the opposite inter-ring node
When the inter-ring node can’t forward traffic because forwarding function failed or one ring function failed.
When the failed inter-ring node recovers.
Passive: When no status messages from opposite inter-ring node are received
Through two rings: the opposite node is down.
Through one ring: one ring function of the opposite node is down.
11/07/2007
IEEE RPRWG

4. controlDataUnit of the status message
Status message could include the following information,
Protection group ID
Forwarding status (None, Traffic set 1, Traffic set 2, Both)
Traffic can be classified by VLAN ID, MAC address and/or other information.
The inter-ring node may forward none, one, or both parts of the traffic.
Under normal status, the forwarding status is decided by configuration or negotiation.
Under protection status, the forwarding status is decided by the protection mechanism.
To TTL balancing method, this field may be not needed.
11/07/2007
IEEE RPRWG

5. controlDataUnit of the status message (cont’)
Failure indication (No Failure, Partial failure, inter-ring forwarding failure) : Indicate the inter-ring node’s forwarding function failure, one ring function failure and the failure’s recovery.
Configuration information (Priority, DevID etc.): May be used to negotiate the forwarding status during initialization or during the running time dynamically.
Any others?
11/07/2007
IEEE RPRWG

6. Back-to-back interconnected PIRC rings
The status of the two back-to-back nodes should be synchronized.
The message is needed to notify the status between two back-to-back nodes. This message is not a RPR message.
Should new message and new mechanism be defined for this scenario?
11/07/2007
IEEE RPRWG

7. Multiple links failure protection
Multiple links failure can be detected by
Status message
One inter-ring node can’t receive the status message from the opposite node through one ring.
But no inter-ring node failure notification is received through the other ring. This can be used to differentiate with one ring RPR function failure.
TP message
In order to protect the inter-ring traffic, both inter-ring nodes should be in forwarding status.
11/07/2007
IEEE RPRWG

8. Transient Loop in PIRC
The possibility of two inter-ring node forwarding when one inter-ring node recovers from failure.
For multiple links failure protection, both inter-ring nodes are in forwarding status. After link defect disappears, there will be transient loop.
In relax mode, transient loop could be tolerated.
In strict mode, transient loop should be avoided.
11/07/2007
IEEE RPRWG

9. Strict mode for loop prevention
In a protection group, anytime only one inter-ring node forwards traffic between the rings.
Don’t support multiple links failure protection.
Guarantee two inter-ring nodes not in forwarding status at the same time.
When one inter-ring node switch into forwarding status, it should make sure that the other one is not in the forwarding status.
Sometime failed inter-ring node should take action and/or notify the other inter-ring node
11/07/2007
IEEE RPRWG

10. Strict mode for loop prevention (cont’)
Modify the node’s recovery mechanism
When inter-ring node recovers, it shouldn’t switch into forwarding status immediately.
When nodes adjacent to the failed link find the link recovers, they shouldn’t switch to normal status immediately.
Timer mechanism
They keep in protected status until their timers expire.
Before the timers expire, the correlative interconnected node shall know the reversion and stop forwarding.
Notification mechanism
They keep in protected status until the correlative interconnected node stops forwarding and notifies them.
11/07/2007
IEEE RPRWG