Abstract: A hierarchical and distributed control architecture for managing an optical communications network. The architecture includes a line card manager level for managing individual line cards in an optical switch, a node manager level for managing multiple line cards in an optical switch/node, and a network management system level for managing multiple optical switches/nodes in a network. An event manager at the node manager level enables software components that are running at the node manager to register for and receive events, and to post events. The events may be triggered, e.g., by a change in a status of the switch, or an alarm condition. Control architecture functionalities include signaling, routing, protection switching and network management. Furthermore, the network management function includes a topology manager, a performance manager, a connection manager, a fault detection manager, and a configuration manager.

Abstract: A facility is provided to allow a supervisory message to quickly propagate through a transmission network without delay. Specifically, a supervisory message is quickly routed from one node to a next node by (a) splitting the control channel signal carrying the supervisory message at a receiving node, (b) sending one of the split control channel signals to an output via switchable apparatus for immediate transmission the next node and (c) sending the other split signal to a controller for analysis. If the controller invokes a predetermined procedure as a result of the content of the message, e.g., invokes protection switching, then the controller forms a supervisory message identifying the invoked procedure, operates the switchable apparatus so that the message identifying the invoked procedure may be routed to the output in place of the split channel signal message.

Abstract: An optical switch architecture in an optical communications network. The imminent removal of a line card from a slot at the optical switch is detected to inform an associated software process/manager that manages the line card that it is going to be removed. The movement of a locking mechanism that locks the line card in its slot triggers a message to a Node Manager that the line card is about to be removed. The software process knows that it will not be able to communicate with the line card, such as to request data or transmit commands. Moreover, the software process knows to not set an alarm for a malfunctioning line card since it will not receive any responses from the removed line card. The software process also maintains information related to the line card during its removal for use when the line card is subsequently re-installed.

Abstract: A hierarchical and distributed control architecture for managing an optical communications network. The architecture includes a line card manager level for managing individual line cards in an optical switch, a node manager level for managing multiple line cards in an optical switch/node, and a network management system level for managing multiple optical switches/nodes in a network. An event manager at the node manager level enables software components that are running at the node manager to register for and receive events, and to post events. The events may be triggered, e.g., by a change in a status of the switch, or an alarm condition. Control architecture functionalities include signaling, routing, protection switching and network management. Furthermore, the network management function includes a topology manager, a performance manager, a connection manager, a fault detection manager, and a configuration manager.

Abstract: A node management architecture for use at an optical switch/node in an optical communications network. A software task is provided for managing each line card according to a type of the line card. The architecture may identify the line card type, and assign a corresponding software task to manage it. To avoid delays, unassigned software tasks may be created ahead of time for managing line cards that are later installed at the optical switch. Furthermore, different types of software tasks are provided for managing corresponding different types of line cards, while software tasks that manage the same type of line card may be organized as an array of the same type. Moreover, the software tasks may act as an intermediary between the line card managers and other software processes at the node manager, such as a database manager, alarms manager, or optical cross-connect manager.

Abstract: An optical switch architecture in an optical communications network. The imminent removal of a line card from a slot at the optical switch is detected to inform an associated software process/manager that manages the line card that it is going to be removed. The movement of a locking mechanism that locks the line card in its slot triggers a message to a Node Manager that the line card is about to be removed. The software process knows that it will not be able to communicate with the line card, such as to request data or transmit commands. Moreover, the software process knows to not set an alarm for a malfunctioning line card since it will not receive any responses from the removed line card. The software process also maintains information related to the line card during its removal for use when the line card is subsequently re-installed.

Abstract: A Line Card Manager (LCM) and Node Manager architecture for use at an optical switch in an optical communications network. LCMs are provided for managing different line cards at the switch, and a Node Manager at the switch manages the LCMs. The Node Manager and LCMs exchange messages using a message-passing interface. The messages may include, e.g., read messages that enable the node manager to retrieve monitored parameter values that the LCM receives from its line card, write messages that enable the node manager to write provisioning data to the LCM, alarm messages that allow the LCMs to report alarm conditions to the node manager, an audit message that enables the node manager to verify a presence of the line card at the optical switch, and discovery messages that allow a LCM to announce its presence to the node manager, e.g., after rebooting.

Abstract: A Line Card Manager (LCM) architecture for use at an optical switch in an optical communications network. A LCM with a dedicated processor is provided for different line cards at the switch. The LCM includes a first interface, such as a connector to the line card, for receiving monitored parameters from the line card, and a processor that executes software for determining when an event such as a fault should be set, e.g., when a monitored parameter is out of range. The LCM has a second interface to a local area network at the switch for reporting the event to a Node Manager, which manages the LCM. The LCM is preferably a removable plug-in module of the line card to allow easy upgrades and maintenance. The LCM includes generic software for managing different types of line cards.