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 [email protected]

CCAMP WG (03/19/03) Peter Czezowski <[email protected]>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


Optical Network Failure Recovery Requirements

• draft-czezowski-optical-recovery-reqs-01.txtPeter 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


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


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


Fault Notification Protocol for GMPLS-Based Recovery

• draft-rabbat-fault-notification-protocol-02.txtRichard 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


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



• 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



• 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


Extensions to LMP for Flooding-based Fault Notification

• draft-soumiya-lmp-fault-notification-ext-00.txtToshio 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


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



• 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>



• 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.



• 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.


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?

recovery requirements, fault notification protocol, and lmp ccamp wg (ietf-56) march 19, 2003

Documents