1 / 15

Recovery Requirements, Fault Notification Protocol, and LMP CCAMP WG (IETF-56) March 19, 2003

Recovery Requirements, Fault Notification Protocol, and LMP CCAMP WG (IETF-56) March 19, 2003. Peter Czezowski peterc@fla.fujitsu.com. Outline. 3 drafts on failure recovery and fault notification draft-czezowski-optical-recovery-reqs-01.txt draft-rabbat-fault-notification-protocol-02.txt

unity-mullen
Download Presentation

Recovery Requirements, Fault Notification Protocol, and LMP CCAMP WG (IETF-56) March 19, 2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  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 Peter Czezowski <peterc@fla.fujitsu.com>

  12. Extensions to LMP for Flooding-based Fault Notification (3) • two additional message formats <FaultNotify Message> ::= <Common Header> <MESSAGE_ID> [<TTL>] <FAULT_ID> <LOCAL_NODE_ID> {<LINK_ID>[<CHANNEL_STATUS>]...} or <FaultNotify Message> ::= <Common Header> <MESSAGE_ID> [<TTL>] <FAULT_ID> [<SRLG ID> ...] <FaultNotifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK> Peter Czezowski <peterc@fla.fujitsu.com>

  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. Peter Czezowski <peterc@fla.fujitsu.com>

  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. Peter Czezowski <peterc@fla.fujitsu.com>

  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? Peter Czezowski <peterc@fla.fujitsu.com>

More Related