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

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 802.17 RPRWG

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 802.17 RPRWG

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 802.17 RPRWG

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 802.17 RPRWG

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 802.17 RPRWG

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 802.17 RPRWG

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 802.17 RPRWG

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 802.17 RPRWG

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 802.17 RPRWG