1. Recovery Requirements, Fault Notification Protocol, and LMP CCAMP WG (IETF-56) March 19, 2003 Peter Czezowski peterc@fla.fujitsu.com

2. CCAMP WG (03/19/03)Peter Czezowski 2 Outline 3 drafts on failure recovery and fault notification –draft-czezowski-optical-recovery-reqs-01.txt –draft-rabbat-fault-notification-protocol-02.txt –draft-soumiya-lmp-fault-notification-ext-00.txt Summary and recommendations

3. CCAMP WG (03/19/03)Peter Czezowski 3 Optical Network Failure Recovery Requirements draft-czezowski-optical-recovery-reqs-01.txt Peter Czezowski (Fujitsu Labs of America) Toshio Soumiya (Fujitsu Laboratories) Kohei Shiomoto (NTT Network Innovation Labs) Shoichiro Seno (Mitsubishi Electric Corp.) describes requirements for control plane-based schemes for recovery from data plane failures starting point for work on protection and restoration schemes, protocols and mechanisms

4. CCAMP WG (03/19/03)Peter Czezowski 4 Optical Network Failure Recovery Requirements (2) organization of the draft –introduction –terminology –failure recovery requirements overview of requirements shared mesh-based recovery failure notification mechanisms list of 17 requirements –conclusions

5. CCAMP WG (03/19/03)Peter Czezowski 5 Optical Network Failure Recovery Requirements (3) four categories of requirements –meet (potentially strict) time constraints –be efficient with resources –scalability of recovery scheme –flexibility of recovery scheme changes since –00.txt –some rewording for clarification –added a figure and example scenario regarding fault notification

6. CCAMP WG (03/19/03)Peter Czezowski 6 Fault Notification Protocol for GMPLS-Based Recovery draft-rabbat-fault-notification-protocol-02.txt Richard Rabbat (Fujitsu Labs of America) Vishal Sharma (Metanoia) Norihiko Shinomiya (Fujitsu Laboratories) Ching-Fong Su (Fujitsu Labs of America) Peter Czezowski (Fujitsu Labs of America) after considering the requirements, it is evident that fault notification is critical for scalability and flexibility of recovery scheme

7. CCAMP WG (03/19/03)Peter Czezowski 7 Fault Notification Protocol for GMPLS-Based Recovery (2) we prefer a “per failure” limited flooding- based approach to fault notification –scalability: per failed link vs. per failed LSP (even when you consider bundling LSP notifications) –flexibility: nodes “off the working path” may take immediate recovery actions policy based proactive

8. CCAMP WG (03/19/03)Peter Czezowski 8 Fault Notification Protocol for GMPLS-Based Recovery (3) organization of the draft –overview –requirements at path set-up –protocol steps fault notification analysis –discussion of notification message delays –description of notification message data –conclusions –appendix: delay calculations

9. CCAMP WG (03/19/03)Peter Czezowski 9 Fault Notification Protocol for GMPLS-Based Recovery (4) changes since –01.txt –some rewording for clarification –addressed issues about nodes that require sequential actions for reconfiguration vs. nodes that allow one-shot reconfiguration –added description of generic fault notification data –removed Appendix B: Algorithm for finding sub-graph

10. CCAMP WG (03/19/03)Peter Czezowski 10 Extensions to LMP for Flooding- based Fault Notification draft-soumiya-lmp-fault-notification-ext-00.txt Toshio Soumiya (Fujitsu Laboratories) Peter Czezowski (Fujitsu Labs of America) Takeo Hamada (Fujitsu Labs of America) Shinya Kanoh (Fujitsu Laboratories) LMP is a good candidate for extension to implement flooding-based fault notification –already includes fault management features –can reuse many protocol objects

11. CCAMP WG (03/19/03)Peter Czezowski 11 Extensions to LMP for Flooding- based Fault Notification (2) organization of the draft –overview –fault recovery scenario –additional LMP message formats –additional LMP object definitions –priority-based recovery –conclusions

12. CCAMP WG (03/19/03)Peter Czezowski 12 Extensions to LMP for Flooding- based Fault Notification (3) two additional message formats ::= [ ] { [ ]...} or ::= [ ] [...] ::=

13. CCAMP WG (03/19/03)Peter Czezowski 13 Extensions to LMP for Flooding- based Fault Notification (4) additional TTL object definition TTL Class (Class = TBD) C-Type = 1, Time to Live (= Hop Count) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TTL: 8 bits This is an unsigned integer to indicate a remaining hop count value. A node receiving a FaultNotify message having a TTL of zero MUST silently discard the message.

14. CCAMP WG (03/19/03)Peter Czezowski 14 Extensions to LMP for Flooding- based Fault Notification (5) additional FAULT_ID object definition FAULT_ID Class (Class = TBD) C-Type = 1, Failure Identifier 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | FaultId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FaultId: 16 bits This MUST be a node-wide unique unsigned integer. The FaultId identifies the sequence of failures. A node increases the value when it detects a failure.

15. CCAMP WG (03/19/03)Peter Czezowski 15 Summary draft-czezowski-optical-recovery-reqs-01.txt –we believe the draft fits within CCAMP charter and complements the work done by P&R Design Team –request for consideration as WG draft draft-rabbat-fault-notification-protocol-02.txt –we believe the draft fits within CCAMP charter and complements the work done by P&R Design Team –request for consideration as WG draft draft-soumiya-lmp-fault-notification-ext-00.txt –we have running code for these extensions –does CCAMP have interest in this draft?