WO2003085543A1 - Intelligent network management system and method - Google Patents

Intelligent network management system and method Download PDF

Info

Publication number
WO2003085543A1
WO2003085543A1 PCT/US2003/010282 US0310282W WO03085543A1 WO 2003085543 A1 WO2003085543 A1 WO 2003085543A1 US 0310282 W US0310282 W US 0310282W WO 03085543 A1 WO03085543 A1 WO 03085543A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
autonomously
cross
information
service
Prior art date
Application number
PCT/US2003/010282
Other languages
French (fr)
Inventor
Brian Minnihan
Gail H. Kibbe
Thomas S. Muir
Gigi A. Harrington
Naveed Alam
Daniel J. Harasty
Original Assignee
Skyoptix, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Skyoptix, Inc. filed Critical Skyoptix, Inc.
Priority to AU2003224832A priority Critical patent/AU2003224832A1/en
Publication of WO2003085543A1 publication Critical patent/WO2003085543A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route

Definitions

  • PSTN Public Switched Telephone Network
  • OAMP&P operation, administration, maintenance, provisioning and planning
  • TIRKS Trunk Inventory Record Keeping System
  • TIRKS is used to track the inventory of the trunks and devices associated with the trunks and keep “accurate" records of such trunks and devices; as is known in the art, a trunk is defined by the circuits riding on the cable media interconnecting two or more circuit switches.
  • TIRKS means much more.
  • the very records that TIRKS maintain are used by other systems to perform OAMP&P functionality in the network, including fault location, service order processing, remedying network exhaust, etc.
  • TIRKS records are at best 80% accurate. For a network with a global reach and hundreds of millions, if not billions, of customers any inaccuracy on the order of tens of percentage points results in considerable operational inefficiencies resulting in associated additional operating costs. In a nutshell, the inaccuracies inherent in TIRKS substantially reduce profitability.
  • FIG. 1 is a high level view of an exemplary architecture commonly used to support client applications 1 and 2 in today's PSTN.
  • the PSTN 8 generally includes at least two layers of networks - a service network layer 30 and a transport network layer 31.
  • the service network is a private network that uses the transport network of the PSTN for data delivery.
  • a first router Rl communicates with a second router R2 through first and second Synchronous Optical NETworks (SONET), 10 and 11, respectively.
  • SONET Synchronous Optical NETworks
  • SONET networks 10 and 11 are themselves connected to a Dense Wavelength Division Multiplex (DWDM) network 20.
  • SONET networks 10 and 11 include a plurality of SONET devices, equipment, or network elements such as Terminal Multiplexers, Add Drop Multiplexers, Digital Cross- Connects, etc., that are linked or connected by various cable media such as optical fiber.
  • DWDM network 20 includes a plurality of Wavelength Division Multiplexers, optical fiber amplifiers, etc., that are connected or coupled together via optical fiber.
  • the routers Rl and R2 can automatically or autonomously discover each other by exchanging messages in accordance with standard network protocols and store the result of such discovery in a routing or look-up table. As such, each router in the service network layer 30 knows all its "neighboring" routers. In this way the devices in the service network layer 30 are relatively "intelligent" in that they allow for construction of a network topology. However, the routers Rl and R2 are not directly connected to each other for the purpose of exchanging data. The exchanging of data or messages between routers Rl and R2 is entirely transparent to the SONET and DWDM networks. That is, at the service network layer Rl and R2 appear to be directly connected to each other as illustrated by dotted line 25 in FIG. 1.
  • the routers Rl and R2 will typically have a plurality of other network devices interposed between them (in the transport network layer 31 for example) that provide the actual connection as is illustrated in FIG. 1. These other network devices do not have the capability to autonomously detect the presence of any "neighboring" devices in their own network domain. In fact, older vintage equipment in the PSTN is not only unable to autonomously detect a neighbor but is incapable of providing such information autonomously or otherwise. In accordance with today's practice in the PSTN, each time a network element is added to the transport network layer 31, telephony personnel manually enter a record of the equipment in the appropriate TIRKS database including its point of connection to the network. This process is often error prone and the magnitude of the error grows each time a new entry is made because that new entry may necessarily include and compound prior errors .
  • transport network layer 31 is shown as being connected to an operational support system (OSS) 35 that may be viewed as one OSS among other OSSs forming a TIRKS 36 family of functions or products.
  • OSS operational support system
  • the OSS 35 may be the OPS/INE system of Telcordia Technologies, Inc., which is used to establish and disconnect network connections as part of a process flow in TIRKS 36 based on a record generated by TIRKS 36.
  • OPS/INE trying to instantiate an action, e . g. , OPS/INE trying to perform a required network function such as establishing a new service path, will not be able to successfully execute that function.
  • the service network layer 30 may be viewed as a relatively high level network of the PSTN that supports "services", e.g., voice, legacy data or IP datagrams.
  • the transport layer 31 may be considered a relatively low level network of the PSTN that supports "transport”. In this view the transport network layer 31 provides a "clear channel" communications path to the services at the service layer network 30. In a typical PSTN, the same transport network supports all "services”.
  • the same transport networks (collectively referred to as the "transport network”) will provide clear channel transport of voice traffic (Plain Old Telephone Service - POTS), legacy data, e.g., X.25 or frame-relay, and IP datagrams.
  • the transport network layer 31 operates at layer 1, the physical layer.
  • layer 2 is the data link layer;
  • layer 3 is the network layer;
  • layer 4 is the transport layer;
  • layer 5 is the session layer;
  • layer 6 is the presentation layer; and layer 7 is the application layer.
  • the transport network layer 31 comprises a mix of technologies originating in the early '60s (e.g., Digital Signal Level 0s (DSOs), DSls) as well as technologies from the '90s (e.g., SONET) and emerging technologies (e.g., DWDM) .
  • DSOs Digital Signal Level 0s
  • SONET Synchronization Layer
  • DWDM emerging technologies
  • the devices of the transport network layer 31 do not know what other devices they are attached to and, more specifically, the route of an end-to-end "transport" service (i.e., a clear-channel "bit" pipe) is indiscernible.
  • an end-to-end "transport” service i.e., a clear-channel "bit” pipe
  • the transport network layer 31 is comprised of physical devices that carry out the actual formatting, transmission, and reception of the data streams that communicate the actual services.
  • the transport network layer 31 may also viewed as having layers in accordance with the North American Digital Hierarchy. At its lowest layer, the transport network layer 31 consists of lower-rate clear-channel connections at the DSO (64 kb/s) rate. At the next signal level up are DSls (1.5Mb/s) which may comprise twenty four DSO channels multiplexed together, each DSO taking one of twenty four time slots within the DS1, or a clear channel 1.5Mb/s pipe without individual DSO time slots. At the next signal level up are DS3s (45 Mb/s) which may comprise twenty eight DS1 channels multiplexed together in twenty eight time slots or a clear channel 45 Mb/s pipe without time slots.
  • DSls 1.5Mb/s
  • DS3s 45 Mb/s
  • STS/OC-1 Synignal Transport Signal/Optical Carrier-1
  • Each STS/OC-1 signal has the capacity to carry 28 DSls in the appropriate timeslots, one DS3, or serve as 52Mb/s clear channel data pipe.
  • the digital hierarchy in turn allows STS/OC-1 signals to be multiplexed in fixed multiples up to OC-192; specifically, one can form STS/OC-3, STS/OC-12, OC- 24, OC-48, and OC-192 signals by multiplexing STS-ls in a specified or standard scheme as set forth by various ANSI standards and Telcordia Technologies, Inc. generic requirements (e.g., GR-253, the disclosure of which is incorporated herein by reference) .
  • transport network is also layered according to the type of physical devices that perform the functionality associated with information delivery.
  • the physical devices may include Digital Cross-Connects Systems
  • DCSs DCSs
  • M13 multiplexers M13 multiplexers
  • TMs SONET Terminal Multiplexers
  • ADMs Add-Drop Multiplexers
  • the DCSs form the highest layer of the transport network and provide a large cross-connect fabric via which signals or circuits at various levels within the previously described digital hierarchy may be routed or switched. For example, a 1/0 cross-connect allows DSO signals within a DS1 to exchange timeslots and thereby be routed to different physical locations.
  • the DCSs are in turn connected together, with clear-channel pipes, at the next lower layer of the transport network, typically by SONET devices.
  • the SONET devices may be connected together at the lowest layer of the transport network by DWDM network devices.
  • DWDM network devices At all layers of the transport network, there are primarily two options: descend to a lower layer (which is typically at a higher transport rate) or direct connections to a "peer" at the same layer. That direct connection could be via a coax cable (e.g., between DCSes in the same location) or via a fiber (e.g., between SONET or DWDM devices at the same or different locations).
  • a coax cable e.g., between DCSes in the same location
  • fiber e.g., between SONET or DWDM devices at the same or different locations.
  • the transport network itself forms a labyrinth within a larger labyrinth that a paper trail is unable to track accurately.
  • the IP service network layer 30 also has physical devices, e.g., IP routers (Rl and R2) and IP switches (not shown in FIG. 1), which are specialized for managing IP services.
  • the physical IP devices within service network layer 30 have the ability to detect the existence of a clear-channel connection between them, but cannot determine how that connection is implemented or established. That is, the IP devices cannot determine the existence of devices within transport network layer 31 because to the IP devices the transport network layer 31 is a clear channel path over which IP services are connected.
  • the IP devices deliver information in the form of bits to the transport network layer 31 which delivers the information to its destination, e.g., from Rl to R2 in FIG. 1.
  • the transport network layer 31 essentially forms a pipe for delivery of the services of the service network layer 30.
  • the service network layer 30 may be a virtual private Local Area Network (LAN) formed over a large geographic area and connected via the PSTN, e.g., a company uses the PSTN to communicate IP datagrams between its employees in New York and California.
  • the manager of the LAN does not work for the telephone company and does not have access to the telephone company's records. Accordingly, when datagrams are not successfully communicated between the locations, the manager calls the telephone company or PSTN service provider. This triggers the telephone company to dispatch personnel to determine the cause of the problem.
  • LAN Local Area Network
  • the first challenge for a dispatched telephone personnel is to determine the route the service takes as it traverses the PSTN in going from New York to California and vice versa (note, signals may traverse different paths in each direction) .
  • the personnel searches the TIRKS record to determine the route.
  • Those records would not reflect recent changes to the path or changes in the many devices that effect transmission of the information. For example, the records would not indicate that several hours ago a craftperson in New York inappropriately used a DS1 signal for the affected customer to establish new service for another customer.
  • the end result is that the inaccurate records cause a customer to lose access to a particular service. This may result in lost revenue for that customer, e.g., each minute lost may result in huge monetary losses for a brokerage house.
  • the customer gets frustrated and seeks another service provider which results in loss of revenue to the original service provider.
  • an intelligent network management system and method is provided to autonomously discover the topology of a network.
  • the system comprises a command translation module, a connection manager module and a frame manager module.
  • the connection manager module is used for communicating with one or more network devices residing in the network.
  • the frame manager module is coupled to the command translation module and the connection manager and is used to manage a message flow between the command translation module and the connection manager.
  • the system additionally includes a database having abstract data objects representative of the network. The database being updated autonomously in response to changes affecting the devices in the network.
  • the frame manager module further includes means for encapsulating the message flow between the command translation module and the connection manager module.
  • the frame manager module may additionally include a function for detecting events generated by the network element.
  • the database may comprise a plurality of databases.
  • the system comprises a software module including a service layer, a topology extraction layer and a device abstraction layer.
  • the software module is coupled to a frame manager and a connection manager.
  • the connection manager is coupled to a network of devices and the frame manager, wherein the frame manager encapsulates data flowing between the connection manager and the network of devices such that the network management system can automatically discover the network of devices.
  • the service layer includes a cross-connect discovery module that autonomously polls and discovers the cross-connect fabrics of the network elements residing on a managed network. Further in accordance with this embodiment, the service layer includes a service discovery module that is able to discover services traversing the network.
  • the topology abstraction layer includes a connection termination point module. This module functions by polling the devices in a network to obtain information related to cross-connections.
  • a method for autonomously creating a network map within a transport network having a plurality of devices comprises inputting selected network data of at least some of the network devices into a database, processing the selected network data and autonomously creating a network map based on the processed selected network data. Further in accordance with the method, changes in the topology of the network are autonomously detected and the network map is updated accordingly.
  • a second set of selected network data may be inputted and the network map may be updated based on the second set of inputted selected network data.
  • inputting the selected network data comprises the step of inputting an equipment identifier and connection information for at least two network devices.
  • the step of processing comprises retrieving command sets and communication requirements associated with at least one of the network devices .
  • a method for autonomously creating a map of the public switched telephone network comprises inputting selected network data for at least some network devices within the network, processing the selected network data.
  • a provisioned service may be traced through the network it traverses. Since it is possible for the system to store the configuration of an actual network and the devices therein, the system will trace services that traverse network elements that start and/or end on a port of a higher rate than the service within the network. To process a trace request, the system will start on a user-specified cross-connect. The system then determines routes that support the service. The routes are then correlated to determine the network configuration of the service. Having the unique capability to determine direction, the system can perform service circuit tracing using any cross-connect within the route or circuit path and thereby produce the entire service path.
  • the service trace method begins with the specification of an equipment identifier and at least one connection termination point identifier for at least one end-point network element in the network. The method then autonomously traces a service in the network based on the equipment identifier and connection termination identifier. Further in accordance with the service trace method, at least one additional connection termination point is discovered on the at least one end-point network element.
  • the step of discovering at least one additional connection termination point on the at least one end-point network element comprises polling the at least one end-point network element for active cross-connects.
  • the method comprises discovering cross-connects of additional network elements in the network based on the specified and discovered connection termination points.
  • the method further comprises traversing the network using the specified and discovered cross-connect information to trace the service.
  • services that can be traced include ring, point-to-point, or broadcast services .
  • a method for autonomously determining a communication route within the public switched telephone network is provided. The method comprises inputting information about a starting point network device and ending-point network device within the public switched telephone network. Cross-connect information relating the starting point device to a first device is then autonomously detected.
  • a segment of the communication route between the starting point device and a first device is autonomously determined, including further cross-connection information relating to the starting point device. Additional segments of the communications route are then autonomously determined and used to construct the route. Further in accordance with the method autonomously detecting a first device comprises accessing a database containing topology information relating to the devices on the network. In addition, autonomously determining a segment comprises correlating cross-connect information relating to the devices on the network.
  • An additional embodiment comprises a computer readable medium having computer-executable instructions for performing a method comprising inputting information about a starting point network device and ending-point network device within the public switched telephone network. Cross-connect information relating the starting point device to a first device is then autonomously detected. A segment of the communication route between the starting point device and a first device is autonomously determined, including further cross-connection information relating to the starting point device. Additional segments of the communications route are then autonomously determined and used to construct the route.
  • a method is provided for designing a route in a network. The method comprises selecting at least one input route parameters from a predetermined set of parameters, automatically selecting segments from a database based on said selected input route parameters and constructing a route based on said selected segments.
  • constructing a route comprises determining the optimum path based on path segments traversing the route.
  • the optimum path may comprise the shortest route, the least-expensive route or the route having the highest available capacity.
  • An additional embodiment of this aspect of the present invention comprises inputting data including a starting point and an ending point into a computer system and accessing a database including information about hardware devices within the public switched telephone network. Pathways relating to the hardware devices are then autonomously identified and a communication route between the starting and ending points is autonomously created by combining at least some of the identified pathways.
  • accessing a database comprises accessing a database having topology information about the public switched telephone network.
  • autonomously creating a communication route comprises correlating the cross-connect information between hardware devices.
  • a computer-readable medium having computer-executable instructions for performing a method.
  • the method comprises detecting a hardware status change within the public switched telephone network and autonomously generating information about the detected hardware status change.
  • the autonomously generated information is then stored in a database where it may be used to provide an updated view of the public switched telephone network.
  • FIG. 1 depicts an exemplary view of a typical communications network
  • FIG. 2A depicts an exemplary view of a network managed by a network management system in accordance with an aspect of the present invention
  • FIG. 2B depicts a network management system in accordance with an aspect of the present invention
  • FIG. 2C illustratively depicts the software architecture of a network management system in accordance with an aspect of the present invention
  • FIG. 3 illustrates an exemplary flow chart of a method in accordance with an aspect of the present invention.
  • FIGS. 4A-4E illustrate data flows between the layers of the software architecture in accordance with an aspect of the present invention
  • FIG. 5A depicts a flow diagram illustrative of our route trace method in accordance with an aspect of our invention
  • FIGS. 5B, 5B-2, 5B-3, 5B-4, and 5B-5 depict a flow diagram in accordance with an embodiment of the trace route process of
  • FIG. 5A
  • FIG. 5C is an exemplary network used to further illustrate the operation of the flow diagram of FIG. 5B and the process of FIG. 5A;
  • FIG. 6A illustrates a route design process for establishing a service path in accordance with an aspect of our invention.
  • FIG. 6B illustrates the sub-steps associated with selecting a service, step 810, of FIG. 6A.
  • FIG. 2A there is shown a public switch telephone network (PSTN) 108 being managed in accordance with an aspect of the present invention.
  • PSTN public switch telephone network
  • FIG. 2A shows network management system or ETM 200 managing the transport network 31.
  • network management system 200 Through its interface at SONET network 11 network management system 200 is able to autonomously discover all the network elements within transport network 31 once the communication parameters have been supplied (e.g., IP address, login, password) .
  • transport network 31 may include other networks such as a DS3 or DS1 network.
  • NMS 200 may be used as a standalone system or may be integrated with the prior art TIRKs system 36 and its operation support systems (OSSs) 36 ⁇ through 36 n .
  • OSSs 36 ⁇ through 36 n may include OPS/INE and other known operation support systems.
  • the NMS 200 may be coupled to TIRKs system 36 via communication link 115 and provide a way by which TIRKS information may be updated in real time.
  • the link 115 may comprise any of a number of packet data networks including TCP over X.25, IP over an Ethernet LAN or any other type of private packet network.
  • our network management system 200 may be advantageously integrated into today's operations network thereby saving costs that would be associated with replacement of that particular functionality in the PSTN.
  • FIG. 1 As FIG.
  • TIRKS may be also coupled to the network 11 via communication link 119, with or without the link 115, to NMS 200.
  • Communication link 119 may comprise packet data networks similar to those available for link 115.
  • the network management system 200 may be used to independently manage and autonomously track the growth of a network thereby allowing for using ETM as an alternative to TIRKS as a network management tool.
  • the view of the transport network as seen from the service network would now include all the intervening network elements between router Rl and R2.
  • a network operator at the service network layer 30 may, through information provided by the NMS 200, discover all the network elements within transport network 31.
  • our network management system 200 provides autodiscovery functionality within the transport network 31 that heretofore was available only at the service network 30.
  • a network operator or provider of PSTN 108 is thereby allowed to operate, administer, manage, plan and provision (OAMP&P) the network based on a real time topology view of the network.
  • the present invention also advantageously allows a network provider to update a TIRKS or similar database without any human intervention.
  • a network operator or provider may realize increased efficiency in network operations which may result in an increase in operating revenue.
  • FIG. 2B there is shown a network management system 200 in accordance with an aspect of the present invention.
  • Network management system 200 can autonomously or automatically create a topology or tree of a network based on selected input information, such as the network address of network devices 201 and 203 and data relating to the manner in which the devices 201 and 203 are interconnected.
  • the system 200 is able to automatically poll network devices 201 and 203 and those devices included in exemplary network 206, retrieves configuration information, and graphs or creates a map of the network topology.
  • modifications to a transport network layer including addition and deletion of network devices, are autonomously updated and the previously created map or network topology diagram is updated to reflect the changed or modified network.
  • the present invention therefore advantageously creates a network map using a novel software process in conjunction with an electronic database of information about the transport network layer itself, rather than the paper-based TIRKS system employed in the prior art. Further in accordance with the present invention, network inefficiencies relating to OAMP&P network functionality are substantially reduced or eliminated because other than inputting the initial required selected information into a database, no further intervention is needed.
  • our system includes a frame manager module 205, a command translation module 210, and a connection manager module 220.
  • the frame manager module 205 encapsulates all communications between the system 200 and the network elements or devices 201 and 203 and thereby shields the other modules from being required to have any device specific knowledge.
  • Frame manager module 205 encompasses other internal processes that support command and response events from and to the system, respectively, and autonomous events generated by the network devices or elements.
  • the command/response function establishes one or more device specific persistent event thread(s). Once connections have been established, control is passed to an event listener which handles all incoming messages and passes them to the appropriate message thread for further processing.
  • the frame manager module 205 uses the command translation module 210 to perform translation to device-type specific commands.
  • Command translation module 210 defines the device specific response syntax which is used by the frame manager 205 to store device information relating to the device configuration and status.
  • the system 200 further includes the ability to call upon this translation logic to display to the user both the device specific data as well as the data abstracted view.
  • the command translation module 210 uses a device configuration profile module 224 ⁇ , for example, to convert system 200 transactions to device specific commands, as well as to convert device specific commands to generic commands.
  • Each device may have its own separate device configuration module 224.
  • the device configuration modules themselves may be arranged in a larger module that comprises all the devices grouped by vendor or supplier or grouped by the type of device, e.g., all DCSs, into separate classes thereby forming a collection of modules 225 having the information included individually in databases DCPi through DCP n .
  • the device configuration profile modules 224 may be thought of as databases wherein profile information that identifies the features and functions of a device or network element are stored in the form of abstract data objects.
  • the device profile configuration module is populated with data that identifies the individual devices, network elements, or equipment, e.g., devices 201 and 203, that comprise a network.
  • individual databases may be populated with information such as the type of equipment, e.g., add-drop multiplexer versus ring node, the equipage of cards available in the equipment, e.g., DS1 termination cards versus DS3 termination cards, the number of racks in the equipment, the mnemonics associated with the layout of the racks or cards making up the equipment, and any other information that is useful in identifying different features associated with the equipment.
  • the device configuration modules or databases 224 may be co- located with the system 200 or may be accessible over a communications network 230. As FIG. 2B also shows the system interfaces with network device 201 over a link 235.
  • the link 235 may include for example TCP over X.25 or IP over an Ethernet LAN.
  • link 235 is the means by which system 200 interfaces with the management modules of the network element or equipment. Such modules are used to monitor and control each network element or plurality of network elements with one connected network element operating as a gateway.
  • link 235 is the access point to the network through which system 200 discovers the topology of a network.
  • the link 235 includes connections to any port on the equipment via which specific equipment commands, using a language such as TL-1, may be used to query the equipment .
  • the system 200 also interfaces with one or more clients 243.
  • Client 243 provides an interface through which a user may instantiate queries and service requests on the system.
  • the system 200 may also interface with other systems 245, such as TIRKS, OPSI/INE, NMA and other proprietary systems that perform OAMP&P functionality within the network.
  • Systems 245 may request and receive autonomous information and updates from system 200. These systems 245 may therefore, via the system 200, also update their view of the network to the most current view.
  • FIG. 2C there is shown an exemplary software architecture diagram 250 of the intelligent network management system 200 in accordance with an aspect of the present invention.
  • the system software architecture 250 may be viewed as comprising three layers, a service layer, a topology abstraction layer, and device abstraction layer, wherein each layer performs specific services or functions.
  • a discovery service module 254 cross-connect discovery module 255, audit module 256, design a route (DAR) module 258 and topology abstraction resource (TAR) module 259 are provided; these modules are described in further detail below.
  • DAR route
  • TAR topology abstraction resource
  • topology object manager At the topology abstraction layer 260 resides a topology object manager (TOM) module 262, an active topology object manager (ATOM) module 264, a connection termination point (CTP) module 266, a port termination point (PTP) module 267, and a topology link 268 module; each of these modules are described in detail hereinbelow where appropriate for elucidating different aspects of the present invention.
  • the device abstraction layer 270 includes a translation service module 275. As FIG. 2C shows the topology abstraction layer 260 sits between the service layer 252 and the device abstraction layer 270 while providing access to database 225.
  • the frame manager 205 transmits and receives messages between the device abstraction layer and the topology abstraction layer and communicates through the connection manager 220 to the network elements.
  • device abstraction layer 270 accesses messages from the frame manager 205 to retrieve command sets and communication requirements based on input parameters.
  • the topology abstraction layer then informs the service layer of the service requested, retrieves or stores information from or to database 225, as is appropriate, and then instantiates the device abstraction layer 270.
  • the device abstraction layer then formulates threads (individual processes within a single application) for dispatch to the appropriate devices using its translation service 275.
  • the threads are sent in the form of commands to the appropriate device or devices and responses are then stored in the appropriate thread. Accordingly, at any given time each device may have multiple threads running concurrently.
  • the service layer 252 includes the processes and business rules needed by the system 200 to carry out services requests.
  • the topology abstraction layer 260 provides or maintains an abstract view of the network (e.g., via database 225).
  • the device abstraction layer 270 manages the devices on the network. For example, when a service is requested, the TAL 260 obtains the processes and business rules associated with the service.
  • the TAL 260 also obtains an abstract view of the network, including the device configurations and their interconnections, by accessing database 225.
  • the abstract data objects that are stored in database 225 may include data structures that represent the connection termination points, the cross- connect matrices and interconnect information relating one device to another device. Cross-connections are made between connection termination points in a network element or device.
  • the abstract data objects are generic representations of device specific information. For example, a connection termination received from a device encoded in accordance with a TL-1 syntax is converted to an abstract data form representative of device identifier and the connection termination point. The processes and/or business rules associated with the service and the abstract view of the network are passed on to the DAL 260, where they are translated into device specific commands. The frame manager 205 then manages the issuance of the device specific commands and any responses thereto.
  • the abstract view of the network provided by the TAL 260 allows the management of a network populated with devices from multiple vendors.
  • the TAL 260 in combination with the DAL 270 enables the system 200 to support services for different vendor equipment or devices . Turning now to FIG.
  • a user instantiates the method by inputting a first set of selected network data into the system.
  • data comprises a network element or equipment identifier of two or more network elements (e.g., 201 and 203 in FIG. 2B) and connection information relevant to the two or more network elements.
  • the network element identifier information may include for example the TCP/IP or X.25 network identifier of the equipment, the name of the equipment, the type of equipment, and/or a logon account number.
  • the network identifier information identifies the equipment at the A-end and the Z-end points on a connection and may generally comprise address data.
  • the connection information comprises, for example, ports on each of the two network elements identified by the network identifier information.
  • the connection information identifies how the two or more network elements are connected to each other and, in general, the network.
  • Such information may be of the form port 1, channel 1 on the A-end equipment and port 5, channel A on the Z-end equipment.
  • port 1 on the A-end element may be the working OC-3 line and channel 1 may be the first STS-1 path in the OC-3 line.
  • port 5-1 may mean the working line of the fifth OC-3 of the twelve possible OC-3 connections the equipment supports and channel A would also mean the first STS-1 path in that OC-3.
  • the network identifier information inputted by a user or system 245 defines an initial network.
  • the system 200 m accordance with this aspect of the present invention, is able to autonomously track topology changes within the network. Extensions or device augmentation of the network will result in automatic updating of the initial network view to include the device augmentation and extension of provisioned services.
  • the connection information essentially defines at a first level the relationship between the network elements within the initial network. As described hereinbelow, once provided with this initial information the system 200 autonomously discovers the cross-connects for each network element in the network, relates the cross-connects across all the network elements, and constructs a network map having all the connections to and from each network element.
  • the first set of selected network information may be input to the system 200 as part of a bulk data transfer and in this way information on large networks can be initially stored and used to autonomously create network maps. Accordingly, users may incrementally grow their network (s) without the system or ETM 200 having the entire network view from the beginning.
  • the system then autonomously creates a network topology map or tree 310 based solely on the user inputted information, step 340.
  • the system 200 uses the user inputted information to access the relevant databases of the plurality of databases DCPi through DCP n . Based on the accessed information the system then queries the equipment through the command translation module to discover the network topology.
  • the query includes discovering the cross connect matrix of the A-end and Z-end network elements.
  • the system discovers the cross-connect matrices of other network elements connected on the network. Once cross-connect matrices are determined further analysis is done to correlate the information including how different network elements are physically connected to each other.
  • the process continues as the system 200 checks for changes in the network topology either due to new user inputted information, e.g., the addition of a new node, or due to the failure of a network element or node. Note, however, that the system 200 does not need this fault information. If a fault occurs and services are re-routed or switched over to protection, ETM will show the new route if the services are traced as is explained in further detail below. In addition, as configurations change the system 200 detects such changes without the user having to notify the system or ETM 200. Such changes include the insertion of a new card, removal of an existing card and activation of a card.
  • Post processing may include marking existing services as invalid (if a card is no longer present) or for inclusion, determining if the new card has been administered and available for provisioning as is required after board insertion (before cross-connects can be established on that board) . If the system 200 does detect a change in the network, the network topology map is recreated at step 366 as previously described in step 340 and a new updated map 370 is then created.
  • An additional aspect in accordance with the present invention is the automated and accurate determination of how cross- connects are configured within various system devices (e.g., SONET boxes and the like) .
  • the system 200 when a user of the system 200 inputs an equipment identifier, the system 200 automatically locates the particular equipment in database 225 and determines its configuration. This is accomplished by retrieving the equipment and the inventory of the specific equipment or device. Once this is performed, the system 200 knows or acquires information relating to the cards (or equipage) of the equipment in addition to the ports associated with each card. Such information may already be stored in database 225 and acquired as previously described. If the information is not in database 225, then it may be retrieved in accordance with the procedure described above in relation to FIG. 2C. The system or ETM 200 then performs a retrieve cross-connect command whereby information about the cross-connect configuration is obtained.
  • automated cross-connect determination may be performed in a network that includes equipment from various vendors.
  • Existing element management systems only permitted this type of discovery where all the network devices were manufactured by the same vendor and were thus compatible.
  • prior art system limited the view of the network to only specific portions where a supplier's equipment having such functionality was coupled to that suppliers equipment.
  • a network comprised an architecture having more than one supplier's network element such prior art systems cannot provide a complete network view.
  • a network grows in complexity, either by addition of network elements or by coupling of previously uncoupled networks, there is a mixture of network elements from a plurality of suppliers or vendors.
  • Other causes include corporate mergers and acquisition which result in the newly formed entity having the task of network integration.
  • the topology abstraction layer 260 accesses the messages received at the frame manager to retrieve the command sets associated with the user service request and the communication requirements of the network element as is shown by line 402. More specifically, the user provides an equipment identifier for network devices, e.g., Device A and Device B, along with the appropriate connection information for the devices. The user may also include a service request such as a request for discovery service 254.
  • the topology abstraction layer (TAL) 260 then accesses the message received at the frame manager to extract information such as the equipment identifier and connectivity information. The extracted information is then used by the TAL 260 to retrieve the command sets associated with the service from the service layer. In addition, the TAL 260 also obtains the communications and other requirements of the device. Once the command sets and communication requirements are available from layer 260, processing continues as shown in FIG. 4B with the frame manager invoking the device abstraction layer 270 to establish threads 406 that are appropriate for the device, device B for example, using the command and communications data retrieved by layer 260. Each thread 406 must however be translated by command translation module 210 into a frame specific device thread 408 that is understandable to the device and is appropriate for communication over network 410.
  • connection manager 220 In accordance with the reference software architecture of FIG. 2C translation is performed by a translation service 275 residing at the DAL 270.
  • the connection manager 220 then further formats the device thread 408 for transmission over the network 410.
  • the device abstraction layer performs functionality at layers 2, 3, and 4 of the 7 Layer Open System Interconnect stack.
  • User Datagram Protocol/Internet Protocol at layers 3 and 4, however, those of ordinary skill in the art will readily recognize that any standard or proprietary layer 3 and 4 protocols may be used to perform this functionality.
  • connection manager 226 as being coded in "C" and running on a Solaris work station, any programming language and platform may be used to carry out the functionality of the connection manager 220.
  • the frame manager 205 need not use JAVA.
  • FIG. 4C there is shown the operation of the device abstraction layer 270 and the topology abstraction layer 260 when device B sends back a response to the command sent in FIG. 4B.
  • generalized or vendor neutral data is sent through the frame manager to the topology abstraction layer which either stores the data for later presentation or processing.
  • FIG. 4D shows the data flow into the device abstraction layer caused by an autonomous notification or event from the device. The data flow is similar to that of FIG. 4C except that the frame manager is not invoked and the data is tagged as an event to distinguish it from a response to a query. Tracking and logging events is important in that is allows our system to track changes in the network in real time.
  • Device A may generate an event message in response to change in the settings of the device.
  • the event message after propagating through the network 410 is detected by the connection manager.
  • the event then generates a frame specific device thread 418 which is then converted to device specific event thread 406 by command translation module 210.
  • the device specific event thread 406 is of a form recognizable by the TAL 260.
  • the device specific event thread 406 is then forwarded to the TAL 260 by an event message module 429 resident in the frame manager.
  • the TAL 260 updates it network view. For example, if there was a rearrangement of cross-connects at Device A, the abstract network view maintained by the TAL 260 is updated to reflect the re-arrangement.
  • FIG. 4E shows that in a real working implementation there will be multiple threads for a plurality of devices running concurrently causing data flow up and down the device abstraction, topology abstraction, and service layer of our system 200.
  • the path or route of a provisioned circuit can be traced through a network based on a topology network map. Since it is possible for the system to store an actual network, the system will trace services that traverse network elements that start and/or end on a port of a higher rate than the service within the network. A user may also specify any cross-connect (including intermediate cross-connects of the service path) from which to begin a trace. Having the unique capability to determine direction, the system can perform service circuit tracing using any cross-connect within the service circuit path and thereby produce the entire service circuit path.
  • the services supported with tracing can be linear or more complex services such as broadcast or multipoint . Turning to FIG.
  • a flow diagram depicting the general method steps associated with a route or circuit tracing process 600 in accordance with this aspect of the present invention.
  • the process is instantiated via a user request in which the user specifies an endpoint network element's identifier (NE ID) and a connection termination point (A or Z) identifier (CTP ID) at step 605 (this may be an intermediate or end point within the circuit path) .
  • NE ID endpoint network element's identifier
  • a or Z connection termination point
  • CTP ID connection termination point
  • the process may instantiated in batch mode by another system, e.g., TIRKS.
  • Such a batch mode request may be set to occur periodically, e.g., daily or monthly.
  • the system 200 traces a route, step 607, to all A and Z endpoint (s), returning all these endpoints, preferably as a network map, as well as a list of the cross-connects used to trace the route.
  • the trace route service is instantiated only a portion of the user's network is known by the system, i.e., the user did not include the network element identifiers for some network elements in the actual network in step 301 of FIG. 3, then some of traced services will end outside the network known to the system 200. Nonetheless, the trace route process provides the capability to trace a route for a service or information path that starts and/or ends on a port of a higher rate than the service.
  • step 607 the process initially discovers the cross-connects on the inputted end-point network elements. Once the cross-connects on the end-point network elements are discovered, the trace route process continues by utilizing three main loops.
  • a first loop, Loop 1 or step 614 traverses from network element to network element to discover the cross connects used for a single leg of the service.
  • a second loop, Loop 2 or step 618 is used in discovering each additional leg of a service, one leg at a time.
  • step 618 returns to the starting point of the service to continue tracing in additional directions.
  • Each service may be comprised of one or more service legs.
  • Each service leg may be comprised of one or more segments.
  • the one or more segments define a service path connecting two network elements to each other. For example, if a service traverses a linear network having three network elements, such a network would have one leg having two segments, each segment connecting one end-point network element to the intermediate network element.
  • the process polls that network element to discover the active cross-connects associated with the intermediate network element and thereby define that segments, e.g., which port connects the neighboring network elements. Segment information is then correlated to define each service leg.
  • a third loop, Loop 3 or step 622 is used only if new legs of the service are discovered while processing a saved connection termination point (CTP) . For example, if the process finds a connection termination point that was not previously logged, this connection termination point must then be traced to determine the segments comprising its service leg and thus discover its service leg.
  • the trace route process 600 ends by returning an A and Z endpoint list(s), a route cross-connect list, along with any errors found in the trace. Alternatively, the cross-connect and endpoint information may be depicted in the form of network map or diagram.
  • the trace route process 600 is able to trace routes on all transport network technologies, including, but not limited to, SONET, DSn, synchronous digital hierarchy (SDH), WDM, and DWDM.
  • SONET synchronous digital hierarchy
  • the trace route process 600 provides the capability to trace a route for a "sub-channel-rate" service which utilizes "tunnel" cross- connects.
  • This feature we refer to this feature as tunneling.
  • Cross- connects for a sub-channel-rate service will be lower than the base timeslot rate. For example, for SONET, the base timeslot rate is STS1.
  • a "sub-channel-rate” in this case could be VT1.5 (Virtual Tributary 1.5), since the STS1 must be channelized to handle the VT1.5.
  • the base timeslot rate is AU .
  • the structure and interfaces in accordance with an SDH network are defined in the ITU standard G.709, the disclosure of which is incorporated by reference herein in its entirety.
  • a "sub-channel-rate” in the case of SDH would be VC-11 (Virtual Channel - 11) .
  • a "tunnel" cross-connect is a cross-connect at a higher rate than the service(s) that traverses it.
  • VT1.5 service usually consists of a series of VT1.5 cross connects, it may be tunneled through one or more STS1 cross connects.
  • the STS1 cross connects in this case would be considered the "tunnel"-cross connects.
  • a number of VT1.5 services may traverse a single STS1 cross-connect. Services which start on, end on, or traverse a "tunnel" cross connect can be traced in accordance with this aspect of our invention .
  • linear, point-to-point, broadcast, and multi-homed circuits can be traced. These circuits or routes traverse different network configurations such as rings, point-to-point or mesh configurations .
  • FIGS. 5B through 5B-5 there is shown a flow diagram in accordance with an embodiment of the trace route process of FIG. 5A.
  • the process begins at step 605 with a user request comprising an endpoint network element's identifier (NE ID) and a connection termination point identifier (CTP ID) .
  • NE ID endpoint network element's identifier
  • CTP ID connection termination point identifier
  • step 610 the cross-connects for end point network elements is then discovered.
  • step 610 includes the initial substep 610 ⁇ of determining whether each network element or device is already managed by the system 200.
  • the system is polled for their respective cross-connect information at step 610 2 .
  • the system 200 attempts to discover the cross connects of that network element at step 610 3 . If the system is unable to discover cross-connects associated with an endpoint network element, line 610 5 , an error message is generated and stored to a return error list at step 640. Such an error message may indicate that the end-point network element, or any other network element, is not connected to the network.
  • the process proceeds to step 622 or loop 3, which is described in detail hereinbelow.
  • step 610 3 If a cross-connect is found at step 610 3 , then the process continues to decision diamond 610 8 to determine whether the cross-connect is carrying service and whether the network element is a WDM at step 610 ⁇ o. If the network element is not a WDM the process adds an error message to the return error list via line 6IO 5 and proceeds to step 622 or loop 3. Note, however, that in an alternative embodiment if the ATOM module software module is included in the system 200, there is no need to invoke poll discovery, 610 2 , of the devices to trace a route. In such an alternative embodiment the topology may be assumed accurate and up-to-date since the ATOM module functions to autonomously track topology changes and update the appropriate databases that are a part of the system 200.
  • step 6IO 1 the process would therefore proceed directly from step 6IO 1 to step 610 8 in such preferred embodiment.
  • the process proceeds to substep 610 ⁇ where the subchannel input levels are determined and saved at 6IO 15 .
  • substep 610 2 an entry connection termination point list or entry list comprising the connection termination points and subchannels is built.
  • the trace direction with respect to each connection termination point of the entry list is determined at step 610 25 as is shown in FIG. 5B-2, by checking whether each connection termination is to the Z-end or to the A-end, substeps 610 27 , 610 29 , and 610 3 ⁇ , respectively.
  • the process then proceeds to step 614 as shown in FIG.
  • loop 1 i.e., loop 1 to determine whether the cross-connect is already processed. This begins with a determination, as is illustrated via decision diamond 614 ⁇ , as to whether the cross-connects are in the route cross-connect list. For any cross-connect found in the cross-connect route list the process proceeds via line 614 5 to add an error message to the return error list at substep 640 and continues to loop 3. However, for each cross-connect found to be not in the cross-connect route list that cross-connect is added to the route list at substep 614 8 . At 614u the from and to cross-connects are determined or parsed. At 614 ⁇ 3 entry and exit cross- connects are then determined.
  • the process continues by selecting an exit connection termination point to trace and save the remaining connection termination points in an entry and exit list along with a subchannel levels field. In this way the process arrives at loop 2 or step 618 (see FIG. 5B-3) where the timeslots in the connection termination points exit lists are stored or retrieved for later use.
  • the connection termination points are traversed by searching for segments. In this way, each service leg is discovered one service leg at a time. This discovery process may be performed in accordance with substeps 618 7 , 618n, and 618 15 . In particular, at 618 7 a parent connection termination point is retrieved. Each time a parent is found, the validity of the line rate of the segment is determined at 618 ⁇ .
  • the process returns to retrieve a parent connection termination at 618 7 and sets a line rate segment validity flag to false. If the line rate segment is determined to be valid, that segment is traversed to the opposite end line rate connection termination point 618 15 and a line rate segment validity flag is not set to false. If there are no more parents and the line rate segment validity flag is set to false, the process proceeds to step 640 along line 610 . On the other hand, if there are no more parents, but no segments are found and the line rate segment validity flag is not set to false the process ends the current trace and updates the A or Z endpoint lists as is shown in substeps 618 2 o, 618 2 ⁇ , and 618 2 2- The process then continues to loop 3 or step 622.
  • a line rate segment is found, as previously noted at 618i 5 , the segment is traversed to its opposite end line rate connection termination point. As shown in FIG. 5B-3, where a valid segment is found processing continues to either substep 618 30 or substep 618 33 . Substep 618 30 is used to find already provisioned connection termination points. Substep 618 33 ends the trace for the current log. There are two conditions that allow processing to continue via substep 6I8 30 . One condition is that a connection termination point rate is set to a predetermined value, lambda (which represents a wavelength or channel in a DWDM system) for example, and that the network element is managed by our system 200, represented as line 6I8 31 .
  • lambda which represents a wavelength or channel in a DWDM system
  • the other condition is that the cross- connection termination point rate is set to lambda and the equipment is a WDM or DWDM, represented as line 618 32 . If either of these conditions is met, then processing continues via 618 30 . In particular, the cross connects are discovered. If the equipment is identified as having an network element ID within the system 200 the network element cross-connections are polled at substep 6I8 35 (see FIG. 5B-5) . If the network element cannot be polled, then at substep 618 37 associated provisioned connection termination points are searched for using the current timeslot sequence, the sub-channel level fields, and the equivalent cross-connect rate. Once the associated segments and cross-connects are found, the process returns via line 618 38 to step 614 and continues processing as described above.
  • a determination as to whether a tunnel cross-connect is used is determined at substep 618 0 .
  • a query is made as to whether the sub-channel level fields are populated at 618 42 - If the sub-channel level fields are populated, then a search is made for the provisioned connection termination points at substep 618 43 . If the search at substep 618 43 is successful, then a tunnel would have been found and the process returns to step 614 and continues processing as described above. If it is determined at substep 618 42 that the sub-channel level fields are not populated, then processing continues to check the validity of the capacity at substep 618 46 . Similarly, if a tunnel was not found at substep 618 43 processing continues to substep 618 6 to check capacity validity. If the capacity validity check proves false processing continues to step 640 via line 6I850.
  • substep 618 33 which ends the trace for the current log.
  • the connection termination point rate is not equal to lambda and the network element type is not set to WDM or DWDM, represented by line 614 48 ; or (2) the cross-connection termination point rate is not equal to lambda and the system is not identified as within our system database, represented by line 614 5 o.
  • the service end point is identified, 6I8 5 1, and the A and Z endpoint lists are updated, 618 5 , with processing continuing to loop 3 or step 622 via line 61866-
  • connection termination point exit list is checked and updated for each new cross connect found.
  • the exit connection termination point lists are checked to determine their fill status, step 622. If the connection termination point exit list is not empty, then at substep 622 3 an exit connection termination point is selected from the exit list and processing returns to loop 2 or step 618. If, on the other hand, the connection termination point exist list is empty, then the fill status of the cross-connect termination entry list is determined as is indicated at substep 622 5 . If the cross connect termination entry list is found to be populated, the process reverses the trace direction by setting an entry connection termination point to an exit termination point, substep 622 9 , and returns to step 618.
  • connection termination point entry list is empty, then a check is made, at substep 622 ⁇ 5 , for new connection termination point entry and exit lists. If a new list is found, processing returns to step 622, otherwise processing continues to step 627 where a return response is formed. In formulating a return response, current or existing errors are checked for on the return error list. If no errors are found the A and Z endpoint lists found along with the route connect lists are presented to the user as part of step 635. If errors are found then the errors, A and Z endpoint lists found, and the route connect lists are presented to the user as part of step 635. To further elucidate our novel trace route process, we will now describe the operation of the process in an exemplary network as depicted in FIG. 5C.
  • the exemplary network of FIG. 5C depicts two ring networks that are connected via SN2, which is an OC-12 line.
  • the first ring is comprised of network elements NE1, NE2, NE3 and NE4.
  • the customer has purchased OC-3 service as indicated by dotted lines 670, 671, and 672 which are, respectively, connected to NE1, NE3, and NE4.
  • the second ring is comprised of NE5, NE6, NE7, and NE8.
  • NE6 and NE7 have not been entered into our system and therefore are not managed by our NMS 200.
  • the user selects NE1 as the endpoint network element (NE) .
  • CTPs provisioned connection termination points
  • PTP1 physical termination point-1
  • TS NE-PTP-Time Slot
  • Subchannel Levels are blank Processing then continues as is shown via the following psuedo code, wherein the steps of FIG. 5B are included at beginning of each line:
  • Step 610 The cross connect in NE1 is found.
  • Step 610 ⁇ 4 Not Applicable (NA)
  • Step 610 20 Add CTP 1-1-1 to the Entry CTP List
  • Step 610 25 Set trace direction to "To Z End” since 1-1-1 is the "From CTP"
  • Step 614 Add NE1 CC to Route Cross Connect List Step 614u: NE1 CC has one "To CTP" - Timeslot
  • Step 618 3 Traverse Installed Line Rate Segment from PTP2 to PTP3.
  • Step 618 30 Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 2-3-1. Loop to Step
  • Step 614 Add NE2 CC to Route Cross Connect List
  • Step 614u NE2 CC has one "To CTP” - Timeslot 1 on PTP4 (2-4-1) and an additional "From CTP" -
  • Timeslot 1 on PTP14 (2-14-1) Traverse to Exit CTP 2-14-1, and add CTP 2-14-1 to Entry CTP List.
  • Step 618 Set Current Timeslot Sequence to 1 (TS sequence on PTP4) .
  • Step 618 3 Traverse Installed Line Rate Segment from PTP4 to PTP5.
  • Step 618 30 Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 5-5-1. Loop to Step 614. Step 614: Add NE5 CC to Route Cross Connect List
  • Step 614n NE5 CC has two "To CTPs" - Timeslot 1 on PTP6 (5-6-1) and Timeslot 1 on PTP9 (5-9-1) . Choose CTP 5-6-1 as Exit CTP to traverse, and add
  • Step 618 Set Current Timeslot Sequence to 1 (TS sequence on PTP6) .
  • Step 618 3 Traverse Installed Line Rate Segment from PTP6 to PTP7.
  • Step 618 30 Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 6-7-1. Loop to Step 614.
  • Step 614 Add NE6 CC to Route Cross Connect List
  • Step 614n NE6 CC has one "To CTP" - Timeslot
  • Step 618 Set Current Timeslot Sequence to 1 (TS sequence on PTP8) .
  • Step 618 3 No segment found
  • Step 618 30 NA
  • Step 6I8 20 Since the Trace Direction is "To Z End", put NE6/CTP 6-8-1 in the Z endpoint list. Step 622: Since the Exit CTP List is not empty
  • Step 618 Set Current Timeslot Sequence to 1 (TS sequence on PTP9) .
  • Step 618 3 Traverse Installed Line Rate Segment from PTP9 td PTP10.
  • Step 618 30 Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 8-10-1. Loop to Step 614.
  • Step 614 Add NE8 CC to Route Cross Connect List
  • Step 614n NE8 CC has one "To CTP" - Timeslot 1 on PTP11 (8-11-1). Traverse to Exit CTP 8-11-1. Step 618: Set Current Timeslot Sequence to 1
  • Step 618 3 Traverse Installed Line Rate Segment from PTP11 to PTP12.
  • Step 618 30 Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 7-12-1. Loop to Step
  • Step 614 Add NE7 CC to Route Cross Connect List
  • Step 614n NE7 CC has one "To CTP" - Timeslot 1 on PTP13 (7-13-1). Traverse to Exit CTP 7-13-1.
  • Step 618 Set Current Timeslot Sequence to 1 (TS sequence on PTP13) .
  • Step 618 3 No segment found Step 618 30 : NA Step 6I8 33 : NA
  • Step 6I8 20 Since the Trace Direction is "To Z End", put NE7/CTP 7-13-1 in the Z endpoint list.
  • Step 622 Since the Exit CTP List is empty, go on to next step.
  • Step 622 5 Since the Entry CTP List is not empty (it currently contains CTP 1-1-1 and 2-14-1) , change Trace Direction from "To Z End” to "To A End", loop to Step 618 using CTP 1-1-1.
  • Step 618 Set Current Timeslot Sequence to 1
  • Step 618 3 No segment found Step 618 30 : NA Step 618 33 : NA
  • Step 6I8 20 Since the Trace Direction is "To A
  • Step 622 Since the Exit CTP List is empty, go on to next step.
  • Step 622 5 Since the Entry CTP List is not empty (it currently contains CTP 2-14-1), loop to
  • Step 618 Set Current Timeslot Sequence to 1 (TS sequence on PTP14) .
  • Step 6I8 3 Traverse Installed Line Rate Segment from PTP14 to PTP15.
  • Step 618 30 Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 3-15-1. Loop to Step 614.
  • Step 614 Add NE3 CC to Route Cross Connect List
  • Step 618 Set Current Timeslot Sequence to 1 (TS sequence on PTP16) .
  • Step 618 3 Traverse Installed Line Rate Segment from PTP16 to PTP17.
  • Step 618 30 Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 4-17-1. Loop to Step 614.
  • Step 614 Add NE4 CC to Route Cross Connect
  • Step 614 ⁇ NE4 CC has one "From CTP" - Timeslot 1 on PTP18 (4-18-1) . Traverse to Exit CTP 4-18-1. Step 618: Set Current Timeslot Sequence to 1
  • Step 618 3 No segment found Step 618 3 o: NA Step 6I8 33 : NA
  • Step 6I820 Since the Trace Direction is "To A
  • Step 622 Since the Exit CTP List is empty, go on to next step.
  • Step 622 5 Since the Entry CTP List is empty, go on to next step.
  • Step 622 15 Since a new Exit CTP List was created, loop to Step 622.
  • Step 618 Set Current Timeslot Sequence to 1 (TS sequence on PTP19) .
  • Step 618 3 No segment found Step 618 30 : NA Step 618 33 : N ⁇
  • Step 6I8 20 Since the Trace Direction is "To A End”, put NE3/CTP 3-19-1 in the A endpoint list.
  • Step 622 Since the Exit CTP List is empty, go on to the next step.
  • Step 622 5 Since the Entry CTP List is empty, go on to next step.
  • Step 622 ⁇ 5 NA
  • Step 627 Return success response with the following data:
  • the system 200 may be used to trace a circuit or service in a network.
  • the service traced may be more complex then a simple point-to- point linear service.
  • the service trace method is able to discover each leg of a service.
  • two legs of service 670 which include the paths PTP1-PTP2-PTP3- PTP4-PTP5-PTP6-PTP7-PTP8 and PTP1-PTP2-PTP3-PTP4-PTP5-PTP9- PTP10-PTP11-PTP12-PTP13, may be traced in accordance with this aspect of the present invention.
  • the starting point (A- endpoint) and an ending point (Z-endpoint) devices may comprise network device 201 and another network device in network 206.
  • the input information may then comprise cross- connect information device 201.
  • the system then autonomously detects the other devices in the network by polling each such device to discover cross-connect and connection termination point information.
  • the system 200 may be equipped with the functionality to allow for augmentation of the network view.
  • the system 200 has the ability to augment a stored network topology map and automatically extend services that traverse the network by intelligently recognizing service affecting events and accurately reflecting these events within the ETM network view .
  • One such event occurs where a service has been "extended" when the network is augmented with new devices that are connected to existing portions of the network and services traverses the new devices.
  • the topology abstraction layer 260 is shown as including an Active Topology Object Manager (ATOM) module 264.
  • ATOM Active Topology Object Manager
  • the ATOM module 264 periodically polls the network elements and cross-connects managed by the system 200 and reconciles any changes that may have occurred on the network. Changes may also be autonomously detected through an event manager residing in the frame manager as discussed in relation to FIG. 4. Accordingly, the ATOM module 264 facilitates detection of service modifications such as network service extensions and service rerouting, regrooming and rehoming.
  • the ATOM module 264 will periodically poll the network elements comprising a managed network to discover the cross-connect fabric of each network element.
  • the cross-connect fabric is then checked against the stored or known information pertaining to each polled network element. If differences are detected, the system 200 then updates the network map to indicate such differences.
  • Topology Link Validity Checks The network management system 200 may also be provided with the additional capability to verify a media, e.g., fiber, that connects two network elements therefore increasing the probability that the media entered is accurate. Such connecting media establishes a topology link for the network elements .
  • the links connecting two network elements in a transport network are not sophisticated. Accordingly, it is necessary to verify that the physical termination points (PTP) at two connected network elements is accurately tracked and reflected by the system too.
  • PTP physical termination points
  • topology link validation is to identify a PTP from the neighboring network element PTP. For example, the path trace function available through the "Jl" byte in SONET, can be set to a specific value at one end of a topology link and read at the other end of the topology link.
  • Another approach is to employ a physical test head at a location within the domain of the network managed by the system 200. The system would then design a route from the test over known links, traverse the link using the test head and looping back the test signal to see if the test signal returns to the test head.
  • a heuristic approach may also be used to check the validity of topology links.
  • the service tracing function is used to find topology links that do not have valid configuration.
  • the system 200 performs the verification by comparing the number of Connection Termination Points (CTPs) associated with each Physical Termination Point (PTP) at either end of the media connecting two network elements and noting the following two conditions: (1) each PTP on the network elements must have the number of CTPs; and (2) each corresponding CTP must be set to the same data rate, be in the same state (active or inactive) and claim the same units. If the CTP's do not match, the system 200 warns the user that the PTP's selected may not be the correct endpoints for the Topological Link.
  • Route Design Turning now to FIG. 6A there is shown a flow chart for route design 800 in accordance with another aspect of the present invention.
  • a service is provided on the system 200 that allows a user to design an end-to-end route for a service.
  • the route design process begins at step 810 when a user indicates the type of service that the user wishes to design by selecting the input route parameters from a pre-determined set of input parameters.
  • the user indicates whether the route will be for a line-to-line service, step 813.
  • the user is required to select, at step 816 input parameters from the following list of parameters: Transport Type (SONET, SDH, Lambda); Rate (OCn, OC1, EC3/STS3E, EC1/STS1E, DS3, DS2, DS1C, DS1A, El, DS1, STMn, STM1, STM1E, E4, STM0, E3, Lambda); A End and Z End network elements; Direction of Service (2 way, 1 way, not specified) ; Protection Class (Normal, Protected, Preemptable) .
  • the user indicates whether the route is for a drop-to-drop service at step 817. If the route design will be a drop-to-drop service the user is then requested to input, in addition to the parameters requested at step 816, the A- End to Z-End ports, as is shown at step 820. As before, once the user defines or selects a service the route design process returns to C in FIG. 6A and continues on to step 830. In the event the user does not select the drop-to-drop option, the service selection process (810) continues to step 821 in FIG. 6B .
  • step 821 the user is prompted to decide whether the service is for drop-to-drop with a higher line rate. If the user selects a design for a drop-to-drop with a higher line rate, then additional information is inputted at step 824.
  • the additional information at step 824 comprises the A End to Z End timeslot identifiers.
  • the route design process returns to C in FIG. 6A and continues on to step 840. If the user still has not chosen a route design service to this point the user is then prompted to determine whether the user wishes to design a route which is a combination of a line to drop or drop to line route, at step 825.
  • a user has a specific service in mind not of the type disclosed above, then the user inputs any sequence of line-to-line and drop-to-drop parameters so as to have a line to drop or drop to line route design constructed at step 826. If the user does not wish to construct a route in accordance with the selection criteria available at step 825, then the process returns to D in FIG. 6A. Once a service is selected as described above with reference to FIG. 6A the process continues to step 840, where segments are selected automatically to construct the route as specified by the user via a route suggestion functionality operating in accordance with an aspect of our invention. A user may also use the route suggestion feature to obtain a list of routes that are compiled for the user.
  • the user has the option to provide the following route search constraints prior to the instantiation of the route suggestion method:
  • a user can also navigate and select from the list of the suggested routes as is or select a list and modify it by deleting and inserting segments manually.
  • a user may also select a suggested route and alter the suggested timeslot of any one of the segments manually by selecting from a list of available timeslots for each segment. If user selects a different timeslot on a segment, the timeslots of all segments in the route that belong to the same subnetwork, as the segment on which the user made the timeslot change, will automatically change to the same timeslot .
  • a route or collection of routes are compiled by setting the following global properties: the maximum number of routes to be found; the initial duration of time to allow the system to find number of routes equal to the value for the maximum number of routes to be found (or at least one route), e.g., a tl threshold; and the total duration of time to allow the System to find number of routes equal to the value for the maximum number of routes to be found, e.g., a t2 threshold.
  • BFS Breadth First Search
  • the routes to be found are for routes with a single or multiple A-ends and single or multiple Z-ends, and a Protection Class of "Normal”, “Protected” or “Preemptable” , then all available timeslots are found. If the routes to be found are for routes with multiple A ends or multiple Z ends, and a Protection Class of "Normal”, “Protected” or “Preemptable”, for each remaining end point (from above step) , using BFS, the shortest spur that meets up with the shortest route and all available Timeslots are found.
  • BFS is used to search the cluster for subnetworks that are "DRIed” first, then the shortest "DRIed” route between one A end and one Z end is found. BFS is continued to find the next shortest route that spans the same DRIed subnetworks as the first one and all available Timeslots found. If no timeslots are found, a BFS is done for the next route found.
  • route is validated for continuous timeslot capacity within each subnetwork across the route. If continuous capacity is not available, BFS is done for the next route found. If continuous capacity is available, the NEs on the route are validated for capabilities to support the route. If NE capabilities do not support the route, BFS is done for the next route found. If NE capabilities support the route, the route is put on a list of suggested routes and BFS is continued for the next route.
  • BFS is continued until the maximum number of routes to be found, specified in corporate data, is reached or the total duration of time to allow the System to find number of routes equal to the value for the maximum number of routes to be found, specified in corporate data, is reached.
  • BFS can be stopped when the initial duration of time to allow the System to find number of routes equal to the value for the maximum number of routes to be found, specified in corporate data, is reached and there is at least one route in the list of routes or can be continued until the total duration of time to allow the System to find number of routes equal to the value for the maximum number of routes to be found, specified in corporate data is reached.
  • Each route in the list is scored in a manner indicative of its relative desirability compared to other routes in the list.
  • the list is sorted from highest to lowest score.
  • the first route on the list is then displayed. Note too that a user may manually design a route by selecting segments from the graphical view or textually specifying NE Ids and Timeslot Ids of each segment, and adding each segment to the route under design. User selections are indicated both graphically and textually, regardless of the method of manual route design.
  • the process may continue to step 860 where a user can request validation of manually designed routes or routes selected from the list of suggested routes but later altered.
  • Step 840 is an optional step which may or may not be required by certain users.
  • the route is validated against disconnects, spurs and gaps.
  • the segments of the route are also validated to provide continuous capacity within each sub-network that the route traverses.
  • the NEs on the route are also validated for support of required route selection parameters.
  • route reservation begins with the inputting of the expiration date for the reservation.
  • a reservation is then created and the route is reserved in topology.
  • a "reservation created” notification task is created and assigned to a user id as a work item, based on the workflow settings.
  • the system then generates a reservation expiration notification task and assigns it to the user id that created the reservation as a work item, 5 days before the expiration date.
  • the reservation is automatically deleted on expiration date if not associated with a work order.
  • Once a reservation is created the process continues at step 890 by updating or deleting a reservation.
  • a reservation may be released by un-reserving the route. Releasing a reservation removes the reservation from the reserved resources (ctps) but leaves them in topology. A user can delete the reservation manually (this removes the reservation and the reserved resource.
  • the system deletes the reservation automatically at expiration date if the reservation is not related to a work order.
  • the reservation expiration date may also be extended.
  • many OAMP&P benefits are realized in the network. For example, because the network topology information is current and accurate, fault location becomes substantially more accurate.
  • turning up of new services can be done much more timely; in particular, in the context of turning up new DSL customers our invention may reduce the time between service order and service delivery by orders of magnitude.
  • Our invention also advantageously allows network operators and providers to break from old legacy systems such as TIRKS seamlessly in a cost efficient manner over any reasonably desired time period.
  • our invention provides heretofore unheard of flexibility in the operation of the network.
  • the DCP databases no longer need to be populated or maintained by the network operator, but may be populated by a third party, including the individual equipment suppliers.
  • the present systems and methods are applicable to software systems and processes for managing a telecommunications network and networks in general.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

A system and method to autonomously discover and track the topology of a network is disclosed. The system autonomously creates or updates a network map representative of an actual network based selected network data of at least some devices on the network. In accordance with a method aspect of the invention the system polls network elements for their cross-connect information and correlates such information to create network maps or trees. Additional aspects of the system include being able to autonomously trace a route or service within a network. In an addition aspect of the invention the system comprises a computer-readable medium having instructions for performing the various methods.

Description

INTELLIGENT NETWORK MANAGEMENT SYSTEM AND METHOD BACKGROUND OF THE INVENTION
The Public Switched Telephone Network (PSTN) comprises a labyrinth of devices connected by various cable media constructed over approximately the last one hundred years. While the labyrinth functions well in terms of reliability and availability of end-to-end services, such as voice communications and data delivery, there is yet a lot to be desired of the PSTN, particularly in relation to the operation, administration, maintenance, provisioning and planning (OAMP&P) functionalities associated with, in general, providing services via the PSTN.
Many of the drawbacks associated with PSTN OAMP&P functionality can be directly or indirectly linked to the systems used to inventory and maintain records of the various devices and connecting media present in the network. One such system is known as the Trunk Inventory Record Keeping System (TIRKS) . As the acronym suggests, TIRKS is used to track the inventory of the trunks and devices associated with the trunks and keep "accurate" records of such trunks and devices; as is known in the art, a trunk is defined by the circuits riding on the cable media interconnecting two or more circuit switches. In practice, TIRKS, however, means much more. Specifically, the very records that TIRKS maintain are used by other systems to perform OAMP&P functionality in the network, including fault location, service order processing, remedying network exhaust, etc. Industry estimates indicate that TIRKS records are at best 80% accurate. For a network with a global reach and hundreds of millions, if not billions, of customers any inaccuracy on the order of tens of percentage points results in considerable operational inefficiencies resulting in associated additional operating costs. In a nutshell, the inaccuracies inherent in TIRKS substantially reduce profitability.
Specifically, and by way of reference to FIG. 1, the impact of TIRKS on the OAMP&P functionality of the PSTN can be better understood. FIG. 1 is a high level view of an exemplary architecture commonly used to support client applications 1 and 2 in today's PSTN. As FIG. 1 shows, the PSTN 8 generally includes at least two layers of networks - a service network layer 30 and a transport network layer 31. However, in some applications the service network is a private network that uses the transport network of the PSTN for data delivery. In the service network layer, a first router Rl communicates with a second router R2 through first and second Synchronous Optical NETworks (SONET), 10 and 11, respectively. SONET networks 10 and 11 are themselves connected to a Dense Wavelength Division Multiplex (DWDM) network 20. SONET networks 10 and 11 include a plurality of SONET devices, equipment, or network elements such as Terminal Multiplexers, Add Drop Multiplexers, Digital Cross- Connects, etc., that are linked or connected by various cable media such as optical fiber. DWDM network 20 includes a plurality of Wavelength Division Multiplexers, optical fiber amplifiers, etc., that are connected or coupled together via optical fiber.
The routers Rl and R2 can automatically or autonomously discover each other by exchanging messages in accordance with standard network protocols and store the result of such discovery in a routing or look-up table. As such, each router in the service network layer 30 knows all its "neighboring" routers. In this way the devices in the service network layer 30 are relatively "intelligent" in that they allow for construction of a network topology. However, the routers Rl and R2 are not directly connected to each other for the purpose of exchanging data. The exchanging of data or messages between routers Rl and R2 is entirely transparent to the SONET and DWDM networks. That is, at the service network layer Rl and R2 appear to be directly connected to each other as illustrated by dotted line 25 in FIG. 1. In reality, the routers Rl and R2 will typically have a plurality of other network devices interposed between them (in the transport network layer 31 for example) that provide the actual connection as is illustrated in FIG. 1. These other network devices do not have the capability to autonomously detect the presence of any "neighboring" devices in their own network domain. In fact, older vintage equipment in the PSTN is not only unable to autonomously detect a neighbor but is incapable of providing such information autonomously or otherwise. In accordance with today's practice in the PSTN, each time a network element is added to the transport network layer 31, telephony personnel manually enter a record of the equipment in the appropriate TIRKS database including its point of connection to the network. This process is often error prone and the magnitude of the error grows each time a new entry is made because that new entry may necessarily include and compound prior errors .
As is further illustrated in FIG. 1, transport network layer 31 is shown as being connected to an operational support system (OSS) 35 that may be viewed as one OSS among other OSSs forming a TIRKS 36 family of functions or products. For example, the OSS 35 may be the OPS/INE system of Telcordia Technologies, Inc., which is used to establish and disconnect network connections as part of a process flow in TIRKS 36 based on a record generated by TIRKS 36. As previously indicated, if 20% of TIRKS records are inaccurate then there is a 20% likelihood that an OSS trying to instantiate an action, e . g. , OPS/INE trying to perform a required network function such as establishing a new service path, will not be able to successfully execute that function. Regardless of whether today's PSTN delivers voice, legacy data or Internet Protocol (IP) datagrams, a hierarchy of network layers exist. The service network layer 30 may be viewed as a relatively high level network of the PSTN that supports "services", e.g., voice, legacy data or IP datagrams. The transport layer 31 may be considered a relatively low level network of the PSTN that supports "transport". In this view the transport network layer 31 provides a "clear channel" communications path to the services at the service layer network 30. In a typical PSTN, the same transport network supports all "services". Thus, the same transport networks (collectively referred to as the "transport network") will provide clear channel transport of voice traffic (Plain Old Telephone Service - POTS), legacy data, e.g., X.25 or frame-relay, and IP datagrams. With respect to the Seven Layer Open System Interconnect reference model (7-Layer OSI) the transport network layer 31 operates at layer 1, the physical layer. Further in accordance with the 7-layer OSI, layer 2 is the data link layer; layer 3 is the network layer; layer 4 is the transport layer; layer 5 is the session layer; layer 6 is the presentation layer; and layer 7 is the application layer. The transport network layer 31 comprises a mix of technologies originating in the early '60s (e.g., Digital Signal Level 0s (DSOs), DSls) as well as technologies from the '90s (e.g., SONET) and emerging technologies (e.g., DWDM) . Unlike the newer services, specifically IP, which was originally defined to support auto-discovery of devices, point-to-point connections between devices, and end-to-end routes (utilizing, for example, the Signaling Network Management Protocol (SNMP) ) , the transport network layer 31 does not have similar "innate" intelligence functionality.
In particular, with the exception of emerging technologies (i.e., DWDM) where some devices from the same vendor, or partnerships of vendors, have been developed with this intelligence, the devices of the transport network layer 31 do not know what other devices they are attached to and, more specifically, the route of an end-to-end "transport" service (i.e., a clear-channel "bit" pipe) is indiscernible. As previously noted however, even in emerging technologies, such as DWDM, the ability to discover neighboring devices is limited to the domain of individual supplier equipment or to suppliers who agree on a proprietary protocol. The transport network layer 31 is comprised of physical devices that carry out the actual formatting, transmission, and reception of the data streams that communicate the actual services. The transport network layer 31 may also viewed as having layers in accordance with the North American Digital Hierarchy. At its lowest layer, the transport network layer 31 consists of lower-rate clear-channel connections at the DSO (64 kb/s) rate. At the next signal level up are DSls (1.5Mb/s) which may comprise twenty four DSO channels multiplexed together, each DSO taking one of twenty four time slots within the DS1, or a clear channel 1.5Mb/s pipe without individual DSO time slots. At the next signal level up are DS3s (45 Mb/s) which may comprise twenty eight DS1 channels multiplexed together in twenty eight time slots or a clear channel 45 Mb/s pipe without time slots. At the next signal level up are STS/OC-1 (Signal Transport Signal/Optical Carrier-1) operating at a bit rate of approximately 52 Mb/s. Each STS/OC-1 signal has the capacity to carry 28 DSls in the appropriate timeslots, one DS3, or serve as 52Mb/s clear channel data pipe. The digital hierarchy in turn allows STS/OC-1 signals to be multiplexed in fixed multiples up to OC-192; specifically, one can form STS/OC-3, STS/OC-12, OC- 24, OC-48, and OC-192 signals by multiplexing STS-ls in a specified or standard scheme as set forth by various ANSI standards and Telcordia Technologies, Inc. generic requirements (e.g., GR-253, the disclosure of which is incorporated herein by reference) .
In another view the transport network is also layered according to the type of physical devices that perform the functionality associated with information delivery. The physical devices may include Digital Cross-Connects Systems
(DCSs), M13 multiplexers, SONET Terminal Multiplexers (TMs) and Add-Drop Multiplexers (ADMs) , SONET ADMs functioning as
Unidirectional Path Switched Ring (UPSR) nodes or as Bi- directional Line Switched Ring (BLSR) nodes, and Wavelength Division Multiplexers (WDMs) and Dense WDMs (DWDMs) . In this layered view the DCSs form the highest layer of the transport network and provide a large cross-connect fabric via which signals or circuits at various levels within the previously described digital hierarchy may be routed or switched. For example, a 1/0 cross-connect allows DSO signals within a DS1 to exchange timeslots and thereby be routed to different physical locations. The DCSs are in turn connected together, with clear-channel pipes, at the next lower layer of the transport network, typically by SONET devices. The SONET devices, in turn, may be connected together at the lowest layer of the transport network by DWDM network devices. At all layers of the transport network, there are primarily two options: descend to a lower layer (which is typically at a higher transport rate) or direct connections to a "peer" at the same layer. That direct connection could be via a coax cable (e.g., between DCSes in the same location) or via a fiber (e.g., between SONET or DWDM devices at the same or different locations). In this way the devices operating at each layer allows for less complex functionality, with the DCS devices having the most complex functionality. As a result, the transport network itself forms a labyrinth within a larger labyrinth that a paper trail is unable to track accurately. The IP service network layer 30 also has physical devices, e.g., IP routers (Rl and R2) and IP switches (not shown in FIG. 1), which are specialized for managing IP services. The physical IP devices within service network layer 30 have the ability to detect the existence of a clear-channel connection between them, but cannot determine how that connection is implemented or established. That is, the IP devices cannot determine the existence of devices within transport network layer 31 because to the IP devices the transport network layer 31 is a clear channel path over which IP services are connected. In any event, the IP devices deliver information in the form of bits to the transport network layer 31 which delivers the information to its destination, e.g., from Rl to R2 in FIG. 1. As such, the transport network layer 31 essentially forms a pipe for delivery of the services of the service network layer 30.
To further elucidate the prior art problems associated with management of the communications network, the following example is provided. The service network layer 30 may be a virtual private Local Area Network (LAN) formed over a large geographic area and connected via the PSTN, e.g., a company uses the PSTN to communicate IP datagrams between its employees in New York and California. The manager of the LAN does not work for the telephone company and does not have access to the telephone company's records. Accordingly, when datagrams are not successfully communicated between the locations, the manager calls the telephone company or PSTN service provider. This triggers the telephone company to dispatch personnel to determine the cause of the problem. The first challenge for a dispatched telephone personnel is to determine the route the service takes as it traverses the PSTN in going from New York to California and vice versa (note, signals may traverse different paths in each direction) . The personnel then searches the TIRKS record to determine the route. Those records, however, would not reflect recent changes to the path or changes in the many devices that effect transmission of the information. For example, the records would not indicate that several hours ago a craftperson in New York inappropriately used a DS1 signal for the affected customer to establish new service for another customer. The end result is that the inaccurate records cause a customer to lose access to a particular service. This may result in lost revenue for that customer, e.g., each minute lost may result in huge monetary losses for a brokerage house. The customer, in turn, gets frustrated and seeks another service provider which results in loss of revenue to the original service provider.
Of utility then are methods and systems that will eliminate or reduce inefficiency in the PSTN, particularly in the context of having the most accurate information available to network operators and OSSs that perform the many OAMP&P functions that are needed to operate a network the size of the PSTN. SUMMARY OF THE INVENTION
In accordance with an aspect of the present invention the foregoing prior art deficiencies are overcome by systems and methods that autonomously discover a network topology. In accordance with an aspect of the invention an intelligent network management system and method is provided to autonomously discover the topology of a network. The system comprises a command translation module, a connection manager module and a frame manager module. The connection manager module is used for communicating with one or more network devices residing in the network. The frame manager module is coupled to the command translation module and the connection manager and is used to manage a message flow between the command translation module and the connection manager. The system additionally includes a database having abstract data objects representative of the network. The database being updated autonomously in response to changes affecting the devices in the network.
In accordance with a further aspect of the system, the frame manager module further includes means for encapsulating the message flow between the command translation module and the connection manager module. In addition, the frame manager module may additionally include a function for detecting events generated by the network element.
Further in accordance with this aspect of the present invention, the database may comprise a plurality of databases.
In accordance with another embodiment of the present invention, the system comprises a software module including a service layer, a topology extraction layer and a device abstraction layer. The software module is coupled to a frame manager and a connection manager. The connection manager is coupled to a network of devices and the frame manager, wherein the frame manager encapsulates data flowing between the connection manager and the network of devices such that the network management system can automatically discover the network of devices.
In accordance with this embodiment the service layer includes a cross-connect discovery module that autonomously polls and discovers the cross-connect fabrics of the network elements residing on a managed network. Further in accordance with this embodiment, the service layer includes a service discovery module that is able to discover services traversing the network.
Further in accordance with this embodiment, the topology abstraction layer includes a connection termination point module. This module functions by polling the devices in a network to obtain information related to cross-connections. In accordance with another aspect of the present invention a method for autonomously creating a network map within a transport network having a plurality of devices is provided. The method comprises inputting selected network data of at least some of the network devices into a database, processing the selected network data and autonomously creating a network map based on the processed selected network data. Further in accordance with the method, changes in the topology of the network are autonomously detected and the network map is updated accordingly.
Further in accordance with the method, a second set of selected network data may be inputted and the network map may be updated based on the second set of inputted selected network data. In addition, inputting the selected network data comprises the step of inputting an equipment identifier and connection information for at least two network devices.
Further in accordance with the method, the step of processing comprises retrieving command sets and communication requirements associated with at least one of the network devices .
In accordance with another embodiment, a method for autonomously creating a map of the public switched telephone network comprises inputting selected network data for at least some network devices within the network, processing the selected network data.
In accordance with another aspect of our invention, a provisioned service may be traced through the network it traverses. Since it is possible for the system to store the configuration of an actual network and the devices therein, the system will trace services that traverse network elements that start and/or end on a port of a higher rate than the service within the network. To process a trace request, the system will start on a user-specified cross-connect. The system then determines routes that support the service. The routes are then correlated to determine the network configuration of the service. Having the unique capability to determine direction, the system can perform service circuit tracing using any cross-connect within the route or circuit path and thereby produce the entire service path. Some of the services or configurations supported with tracing can be ring, point-to-point or more complex such as a mesh. In accordance with this aspect of the present invention, the service trace method begins with the specification of an equipment identifier and at least one connection termination point identifier for at least one end-point network element in the network. The method then autonomously traces a service in the network based on the equipment identifier and connection termination identifier. Further in accordance with the service trace method, at least one additional connection termination point is discovered on the at least one end-point network element.
In addition, the step of discovering at least one additional connection termination point on the at least one end-point network element comprises polling the at least one end-point network element for active cross-connects.
Further in accordance with this aspect of the present invention, the method comprises discovering cross-connects of additional network elements in the network based on the specified and discovered connection termination points. The method further comprises traversing the network using the specified and discovered cross-connect information to trace the service. In accordance with the method, services that can be traced include ring, point-to-point, or broadcast services . In accordance with a further embodiment, a method for autonomously determining a communication route within the public switched telephone network is provided. The method comprises inputting information about a starting point network device and ending-point network device within the public switched telephone network. Cross-connect information relating the starting point device to a first device is then autonomously detected. A segment of the communication route between the starting point device and a first device is autonomously determined, including further cross-connection information relating to the starting point device. Additional segments of the communications route are then autonomously determined and used to construct the route. Further in accordance with the method autonomously detecting a first device comprises accessing a database containing topology information relating to the devices on the network. In addition, autonomously determining a segment comprises correlating cross-connect information relating to the devices on the network.
An additional embodiment comprises a computer readable medium having computer-executable instructions for performing a method comprising inputting information about a starting point network device and ending-point network device within the public switched telephone network. Cross-connect information relating the starting point device to a first device is then autonomously detected. A segment of the communication route between the starting point device and a first device is autonomously determined, including further cross-connection information relating to the starting point device. Additional segments of the communications route are then autonomously determined and used to construct the route. In yet another aspect of the invention, a method is provided for designing a route in a network. The method comprises selecting at least one input route parameters from a predetermined set of parameters, automatically selecting segments from a database based on said selected input route parameters and constructing a route based on said selected segments.
In accordance with this aspect of the invention, constructing a route comprises determining the optimum path based on path segments traversing the route. The optimum path may comprise the shortest route, the least-expensive route or the route having the highest available capacity.
An additional embodiment of this aspect of the present invention comprises inputting data including a starting point and an ending point into a computer system and accessing a database including information about hardware devices within the public switched telephone network. Pathways relating to the hardware devices are then autonomously identified and a communication route between the starting and ending points is autonomously created by combining at least some of the identified pathways. In accordance with this additional embodiment, accessing a database comprises accessing a database having topology information about the public switched telephone network. Further, autonomously creating a communication route comprises correlating the cross-connect information between hardware devices.
In accordance with another aspect of the present invention, a computer-readable medium having computer-executable instructions for performing a method is provided. The method comprises detecting a hardware status change within the public switched telephone network and autonomously generating information about the detected hardware status change. The autonomously generated information is then stored in a database where it may be used to provide an updated view of the public switched telephone network.
The above systems and methods will be better understood when considered in conjunction with the following detailed description and associated drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 depicts an exemplary view of a typical communications network; FIG. 2A depicts an exemplary view of a network managed by a network management system in accordance with an aspect of the present invention;
FIG. 2B depicts a network management system in accordance with an aspect of the present invention; FIG. 2C illustratively depicts the software architecture of a network management system in accordance with an aspect of the present invention;
FIG. 3 illustrates an exemplary flow chart of a method in accordance with an aspect of the present invention. FIGS. 4A-4E illustrate data flows between the layers of the software architecture in accordance with an aspect of the present invention;
FIG. 5A depicts a flow diagram illustrative of our route trace method in accordance with an aspect of our invention; FIGS. 5B, 5B-2, 5B-3, 5B-4, and 5B-5 depict a flow diagram in accordance with an embodiment of the trace route process of
FIG. 5A;
FIG. 5C is an exemplary network used to further illustrate the operation of the flow diagram of FIG. 5B and the process of FIG. 5A; FIG. 6A illustrates a route design process for establishing a service path in accordance with an aspect of our invention; and
FIG. 6B illustrates the sub-steps associated with selecting a service, step 810, of FIG. 6A.
DETAILED DESCRIPTION OF THE INVENTION
System and Method
Our inventive system and method facilitates the autonomous development of a network topology or tree based on selected network information. Various aspects of the present invention will be marketed by SkyOptix, Inc. of New Jersey under the trademark Enhanced Transport Management. The terms ETM or enhanced transport manager and NMS or network management system are used interchangeably hereinbelow to refer to an exemplary system embodying the present invention. Turning now to FIG. 2A there is shown a public switch telephone network (PSTN) 108 being managed in accordance with an aspect of the present invention. In particular, FIG. 2A shows network management system or ETM 200 managing the transport network 31. Through its interface at SONET network 11 network management system 200 is able to autonomously discover all the network elements within transport network 31 once the communication parameters have been supplied (e.g., IP address, login, password) . In addition to SONET network 11 and DWDM network 20, transport network 31 may include other networks such as a DS3 or DS1 network.
As FIG. 2A shows, NMS 200 may be used as a standalone system or may be integrated with the prior art TIRKs system 36 and its operation support systems (OSSs) 36χ through 36n. OSSs 36ι through 36n may include OPS/INE and other known operation support systems. The NMS 200 may be coupled to TIRKs system 36 via communication link 115 and provide a way by which TIRKS information may be updated in real time. The link 115 may comprise any of a number of packet data networks including TCP over X.25, IP over an Ethernet LAN or any other type of private packet network. As such, our network management system 200 may be advantageously integrated into today's operations network thereby saving costs that would be associated with replacement of that particular functionality in the PSTN. Furthermore, as FIG. 2A shows TIRKS may be also coupled to the network 11 via communication link 119, with or without the link 115, to NMS 200. Communication link 119 may comprise packet data networks similar to those available for link 115. Thus, our system may be integrated into today's network or operate independently. In addition, the network management system 200 may be used to independently manage and autonomously track the growth of a network thereby allowing for using ETM as an alternative to TIRKS as a network management tool. In accordance with our invention, the view of the transport network as seen from the service network would now include all the intervening network elements between router Rl and R2. Therefore, although at the service layer router Rl may be viewed as being directly connected to R2 via data line 25, a network operator at the service network layer 30 may, through information provided by the NMS 200, discover all the network elements within transport network 31. As such, our network management system 200 provides autodiscovery functionality within the transport network 31 that heretofore was available only at the service network 30. By using our network management system 200, a network operator or provider of PSTN 108 is thereby allowed to operate, administer, manage, plan and provision (OAMP&P) the network based on a real time topology view of the network.
The present invention also advantageously allows a network provider to update a TIRKS or similar database without any human intervention. By using our network management system, a network operator or provider may realize increased efficiency in network operations which may result in an increase in operating revenue. Specifically, turning now to FIG. 2B there is shown a network management system 200 in accordance with an aspect of the present invention. Network management system 200 can autonomously or automatically create a topology or tree of a network based on selected input information, such as the network address of network devices 201 and 203 and data relating to the manner in which the devices 201 and 203 are interconnected. Once provided with this information the system 200 is able to automatically poll network devices 201 and 203 and those devices included in exemplary network 206, retrieves configuration information, and graphs or creates a map of the network topology. In accordance with another aspect of the invention, modifications to a transport network layer, including addition and deletion of network devices, are autonomously updated and the previously created map or network topology diagram is updated to reflect the changed or modified network.
The present invention therefore advantageously creates a network map using a novel software process in conjunction with an electronic database of information about the transport network layer itself, rather than the paper-based TIRKS system employed in the prior art. Further in accordance with the present invention, network inefficiencies relating to OAMP&P network functionality are substantially reduced or eliminated because other than inputting the initial required selected information into a database, no further intervention is needed. In accordance with FIG. 2B, our system includes a frame manager module 205, a command translation module 210, and a connection manager module 220. The frame manager module 205 encapsulates all communications between the system 200 and the network elements or devices 201 and 203 and thereby shields the other modules from being required to have any device specific knowledge. Frame manager module 205 encompasses other internal processes that support command and response events from and to the system, respectively, and autonomous events generated by the network devices or elements. The command/response function establishes one or more device specific persistent event thread(s). Once connections have been established, control is passed to an event listener which handles all incoming messages and passes them to the appropriate message thread for further processing. The frame manager module 205 uses the command translation module 210 to perform translation to device-type specific commands. Command translation module 210 defines the device specific response syntax which is used by the frame manager 205 to store device information relating to the device configuration and status. The system 200 further includes the ability to call upon this translation logic to display to the user both the device specific data as well as the data abstracted view. The command translation module 210 uses a device configuration profile module 224ι, for example, to convert system 200 transactions to device specific commands, as well as to convert device specific commands to generic commands.
Each device may have its own separate device configuration module 224. The device configuration modules themselves may be arranged in a larger module that comprises all the devices grouped by vendor or supplier or grouped by the type of device, e.g., all DCSs, into separate classes thereby forming a collection of modules 225 having the information included individually in databases DCPi through DCPn. In fact, the device configuration profile modules 224 may be thought of as databases wherein profile information that identifies the features and functions of a device or network element are stored in the form of abstract data objects. Typically, the device profile configuration module is populated with data that identifies the individual devices, network elements, or equipment, e.g., devices 201 and 203, that comprise a network. In accordance with an embodiment of the system 200, individual databases may be populated with information such as the type of equipment, e.g., add-drop multiplexer versus ring node, the equipage of cards available in the equipment, e.g., DS1 termination cards versus DS3 termination cards, the number of racks in the equipment, the mnemonics associated with the layout of the racks or cards making up the equipment, and any other information that is useful in identifying different features associated with the equipment. The device configuration modules or databases 224 may be co- located with the system 200 or may be accessible over a communications network 230. As FIG. 2B also shows the system interfaces with network device 201 over a link 235. The link 235 may include for example TCP over X.25 or IP over an Ethernet LAN. In general, link 235 is the means by which system 200 interfaces with the management modules of the network element or equipment. Such modules are used to monitor and control each network element or plurality of network elements with one connected network element operating as a gateway. For example, and as is discussed below, link 235 is the access point to the network through which system 200 discovers the topology of a network. The link 235 includes connections to any port on the equipment via which specific equipment commands, using a language such as TL-1, may be used to query the equipment .
The system 200 also interfaces with one or more clients 243. Client 243 provides an interface through which a user may instantiate queries and service requests on the system. In addition, the system 200 may also interface with other systems 245, such as TIRKS, OPSI/INE, NMA and other proprietary systems that perform OAMP&P functionality within the network. Systems 245 may request and receive autonomous information and updates from system 200. These systems 245 may therefore, via the system 200, also update their view of the network to the most current view.
Turning to FIG. 2C there is shown an exemplary software architecture diagram 250 of the intelligent network management system 200 in accordance with an aspect of the present invention. As FIG. 2C shows, the system software architecture 250 may be viewed as comprising three layers, a service layer, a topology abstraction layer, and device abstraction layer, wherein each layer performs specific services or functions. Specifically, at the service layer 252 a discovery service module 254, cross-connect discovery module 255, audit module 256, design a route (DAR) module 258 and topology abstraction resource (TAR) module 259 are provided; these modules are described in further detail below. At the topology abstraction layer 260 resides a topology object manager (TOM) module 262, an active topology object manager (ATOM) module 264, a connection termination point (CTP) module 266, a port termination point (PTP) module 267, and a topology link 268 module; each of these modules are described in detail hereinbelow where appropriate for elucidating different aspects of the present invention. The device abstraction layer 270 includes a translation service module 275. As FIG. 2C shows the topology abstraction layer 260 sits between the service layer 252 and the device abstraction layer 270 while providing access to database 225. The frame manager 205 transmits and receives messages between the device abstraction layer and the topology abstraction layer and communicates through the connection manager 220 to the network elements.
By way of a general overview description, device abstraction layer 270 accesses messages from the frame manager 205 to retrieve command sets and communication requirements based on input parameters. The topology abstraction layer then informs the service layer of the service requested, retrieves or stores information from or to database 225, as is appropriate, and then instantiates the device abstraction layer 270. The device abstraction layer then formulates threads (individual processes within a single application) for dispatch to the appropriate devices using its translation service 275. The threads are sent in the form of commands to the appropriate device or devices and responses are then stored in the appropriate thread. Accordingly, at any given time each device may have multiple threads running concurrently.
More specifically, the service layer 252 includes the processes and business rules needed by the system 200 to carry out services requests. The topology abstraction layer 260 provides or maintains an abstract view of the network (e.g., via database 225). The device abstraction layer 270 manages the devices on the network. For example, when a service is requested, the TAL 260 obtains the processes and business rules associated with the service. The TAL 260 also obtains an abstract view of the network, including the device configurations and their interconnections, by accessing database 225. In an embodiment the abstract data objects that are stored in database 225 may include data structures that represent the connection termination points, the cross- connect matrices and interconnect information relating one device to another device. Cross-connections are made between connection termination points in a network element or device. The abstract data objects are generic representations of device specific information. For example, a connection termination received from a device encoded in accordance with a TL-1 syntax is converted to an abstract data form representative of device identifier and the connection termination point. The processes and/or business rules associated with the service and the abstract view of the network are passed on to the DAL 260, where they are translated into device specific commands. The frame manager 205 then manages the issuance of the device specific commands and any responses thereto. In accordance with this aspect of the invention, the abstract view of the network provided by the TAL 260 allows the management of a network populated with devices from multiple vendors. The TAL 260 in combination with the DAL 270 enables the system 200 to support services for different vendor equipment or devices . Turning now to FIG. 3 there is shown a flow diagram illustrating a process or method for creating a network map 300 in accordance with an aspect of the present invention. At step 301 a user instantiates the method by inputting a first set of selected network data into the system. At a minimum that data comprises a network element or equipment identifier of two or more network elements (e.g., 201 and 203 in FIG. 2B) and connection information relevant to the two or more network elements. The network element identifier information may include for example the TCP/IP or X.25 network identifier of the equipment, the name of the equipment, the type of equipment, and/or a logon account number. In general, the network identifier information identifies the equipment at the A-end and the Z-end points on a connection and may generally comprise address data. The connection information comprises, for example, ports on each of the two network elements identified by the network identifier information. In particular, the connection information identifies how the two or more network elements are connected to each other and, in general, the network. Such information, for example, may be of the form port 1, channel 1 on the A-end equipment and port 5, channel A on the Z-end equipment. Assuming the A-end equipment to be a SONET terminal multiplexer, port 1 on the A-end element may be the working OC-3 line and channel 1 may be the first STS-1 path in the OC-3 line. On the Z-end, assuming the equipment to be SONET STS-1 cross-connect, port 5-1 may mean the working line of the fifth OC-3 of the twelve possible OC-3 connections the equipment supports and channel A would also mean the first STS-1 path in that OC-3.
The network identifier information inputted by a user or system 245 defines an initial network. However, once this initial network is designed, the system 200, m accordance with this aspect of the present invention, is able to autonomously track topology changes within the network. Extensions or device augmentation of the network will result in automatic updating of the initial network view to include the device augmentation and extension of provisioned services. The connection information essentially defines at a first level the relationship between the network elements within the initial network. As described hereinbelow, once provided with this initial information the system 200 autonomously discovers the cross-connects for each network element in the network, relates the cross-connects across all the network elements, and constructs a network map having all the connections to and from each network element. In accordance with an embodiment of the system 200, the first set of selected network information may be input to the system 200 as part of a bulk data transfer and in this way information on large networks can be initially stored and used to autonomously create network maps. Accordingly, users may incrementally grow their network (s) without the system or ETM 200 having the entire network view from the beginning. In accordance with this aspect of our invention, the system then autonomously creates a network topology map or tree 310 based solely on the user inputted information, step 340. In particular, the system 200 uses the user inputted information to access the relevant databases of the plurality of databases DCPi through DCPn. Based on the accessed information the system then queries the equipment through the command translation module to discover the network topology. At a first level the query includes discovering the cross connect matrix of the A-end and Z-end network elements. Next, starting at either the A-end or Z-end, the system discovers the cross-connect matrices of other network elements connected on the network. Once cross-connect matrices are determined further analysis is done to correlate the information including how different network elements are physically connected to each other.
At step 360 the process continues as the system 200 checks for changes in the network topology either due to new user inputted information, e.g., the addition of a new node, or due to the failure of a network element or node. Note, however, that the system 200 does not need this fault information. If a fault occurs and services are re-routed or switched over to protection, ETM will show the new route if the services are traced as is explained in further detail below. In addition, as configurations change the system 200 detects such changes without the user having to notify the system or ETM 200. Such changes include the insertion of a new card, removal of an existing card and activation of a card. Post processing may include marking existing services as invalid (if a card is no longer present) or for inclusion, determining if the new card has been administered and available for provisioning as is required after board insertion (before cross-connects can be established on that board) . If the system 200 does detect a change in the network, the network topology map is recreated at step 366 as previously described in step 340 and a new updated map 370 is then created.
An additional aspect in accordance with the present invention is the automated and accurate determination of how cross- connects are configured within various system devices (e.g., SONET boxes and the like) . In accordance with this inventive aspect, when a user of the system 200 inputs an equipment identifier, the system 200 automatically locates the particular equipment in database 225 and determines its configuration. This is accomplished by retrieving the equipment and the inventory of the specific equipment or device. Once this is performed, the system 200 knows or acquires information relating to the cards (or equipage) of the equipment in addition to the ports associated with each card. Such information may already be stored in database 225 and acquired as previously described. If the information is not in database 225, then it may be retrieved in accordance with the procedure described above in relation to FIG. 2C. The system or ETM 200 then performs a retrieve cross-connect command whereby information about the cross-connect configuration is obtained.
In accordance with this aspect of the present invention, automated cross-connect determination may be performed in a network that includes equipment from various vendors. Existing element management systems only permitted this type of discovery where all the network devices were manufactured by the same vendor and were thus compatible. As such, prior art system limited the view of the network to only specific portions where a supplier's equipment having such functionality was coupled to that suppliers equipment. However, where a network comprised an architecture having more than one supplier's network element, such prior art systems cannot provide a complete network view. As is usually the case as a network grows in complexity, either by addition of network elements or by coupling of previously uncoupled networks, there is a mixture of network elements from a plurality of suppliers or vendors. Other causes include corporate mergers and acquisition which result in the newly formed entity having the task of network integration. In addition, many customers are not comfortable designing their next generation network architecture around a single device vendor. As such, our inventive system is able to track a network even as it grows with the addition of network elements from many different suppliers. Accordingly, a network provider is able to manage its network in a supplier independent or neutral manner. Additionally, if a customer prefers to manage their network using device specific details (AID'S etc.) ETM has a unique capability to translate between device specific commands as well as a normalized view of this data. This flexibility provides the user the capability of supporting various levels of experience within their own provisioning centers, from novice technicians to more device experienced technicians. Turning now to FIGS. 4A-4E there is depicted a more detailed illustrative example of the operation of an embodiment of the system 200 in accordance with the exemplary software architecture of FIG. 2C and the general method of FIG. 3. In particular, in FIG. 4A, based on the input parameters selected by a user as part of the instantiation of a service at the service layer, the topology abstraction layer 260 accesses the messages received at the frame manager to retrieve the command sets associated with the user service request and the communication requirements of the network element as is shown by line 402. More specifically, the user provides an equipment identifier for network devices, e.g., Device A and Device B, along with the appropriate connection information for the devices. The user may also include a service request such as a request for discovery service 254. The topology abstraction layer (TAL) 260 then accesses the message received at the frame manager to extract information such as the equipment identifier and connectivity information. The extracted information is then used by the TAL 260 to retrieve the command sets associated with the service from the service layer. In addition, the TAL 260 also obtains the communications and other requirements of the device. Once the command sets and communication requirements are available from layer 260, processing continues as shown in FIG. 4B with the frame manager invoking the device abstraction layer 270 to establish threads 406 that are appropriate for the device, device B for example, using the command and communications data retrieved by layer 260. Each thread 406 must however be translated by command translation module 210 into a frame specific device thread 408 that is understandable to the device and is appropriate for communication over network 410. In accordance with the reference software architecture of FIG. 2C translation is performed by a translation service 275 residing at the DAL 270. The connection manager 220 then further formats the device thread 408 for transmission over the network 410. In accordance with this particular embodiment the device abstraction layer performs functionality at layers 2, 3, and 4 of the 7 Layer Open System Interconnect stack. In accordance with this particular embodiment we have used User Datagram Protocol/Internet Protocol at layers 3 and 4, however, those of ordinary skill in the art will readily recognize that any standard or proprietary layer 3 and 4 protocols may be used to perform this functionality. In addition, although we show the connection manager 226 as being coded in "C" and running on a Solaris work station, any programming language and platform may be used to carry out the functionality of the connection manager 220. Similarly, the frame manager 205 need not use JAVA.
Turning now to FIG. 4C there is shown the operation of the device abstraction layer 270 and the topology abstraction layer 260 when device B sends back a response to the command sent in FIG. 4B. In particular, after the last thread is received, generalized or vendor neutral data is sent through the frame manager to the topology abstraction layer which either stores the data for later presentation or processing. FIG. 4D shows the data flow into the device abstraction layer caused by an autonomous notification or event from the device. The data flow is similar to that of FIG. 4C except that the frame manager is not invoked and the data is tagged as an event to distinguish it from a response to a query. Tracking and logging events is important in that is allows our system to track changes in the network in real time. In particular, Device A may generate an event message in response to change in the settings of the device. The event message after propagating through the network 410 is detected by the connection manager. The event then generates a frame specific device thread 418 which is then converted to device specific event thread 406 by command translation module 210. The device specific event thread 406 is of a form recognizable by the TAL 260. The device specific event thread 406 is then forwarded to the TAL 260 by an event message module 429 resident in the frame manager. Depending on the content of the event thread 406, the TAL 260 then updates it network view. For example, if there was a rearrangement of cross-connects at Device A, the abstract network view maintained by the TAL 260 is updated to reflect the re-arrangement.
FIG. 4E shows that in a real working implementation there will be multiple threads for a plurality of devices running concurrently causing data flow up and down the device abstraction, topology abstraction, and service layer of our system 200.
Circuit/Route Tracing In accordance with another aspect of the present invention, the path or route of a provisioned circuit can be traced through a network based on a topology network map. Since it is possible for the system to store an actual network, the system will trace services that traverse network elements that start and/or end on a port of a higher rate than the service within the network. A user may also specify any cross-connect (including intermediate cross-connects of the service path) from which to begin a trace. Having the unique capability to determine direction, the system can perform service circuit tracing using any cross-connect within the service circuit path and thereby produce the entire service circuit path. The services supported with tracing can be linear or more complex services such as broadcast or multipoint . Turning to FIG. 5A, there is shown a flow diagram depicting the general method steps associated with a route or circuit tracing process 600 in accordance with this aspect of the present invention. The process is instantiated via a user request in which the user specifies an endpoint network element's identifier (NE ID) and a connection termination point (A or Z) identifier (CTP ID) at step 605 (this may be an intermediate or end point within the circuit path) . In an alternative embodiment, the process may instantiated in batch mode by another system, e.g., TIRKS. Such a batch mode request may be set to occur periodically, e.g., daily or monthly. Once provided with this information the system 200 traces a route, step 607, to all A and Z endpoint (s), returning all these endpoints, preferably as a network map, as well as a list of the cross-connects used to trace the route. If at the time the trace route service is instantiated only a portion of the user's network is known by the system, i.e., the user did not include the network element identifiers for some network elements in the actual network in step 301 of FIG. 3, then some of traced services will end outside the network known to the system 200. Nonetheless, the trace route process provides the capability to trace a route for a service or information path that starts and/or ends on a port of a higher rate than the service.
In tracing a route, step 607, the process initially discovers the cross-connects on the inputted end-point network elements. Once the cross-connects on the end-point network elements are discovered, the trace route process continues by utilizing three main loops. A first loop, Loop 1 or step 614, traverses from network element to network element to discover the cross connects used for a single leg of the service. A second loop, Loop 2 or step 618, is used in discovering each additional leg of a service, one leg at a time. In particular, where a service, e.g., broadcast service, has multiple service legs, step 618 returns to the starting point of the service to continue tracing in additional directions. Once step 618 reaches an endpoint, the process returns to the beginning of Loop 2 to start a new leg. Each service may be comprised of one or more service legs. Each service leg may be comprised of one or more segments. The one or more segments define a service path connecting two network elements to each other. For example, if a service traverses a linear network having three network elements, such a network would have one leg having two segments, each segment connecting one end-point network element to the intermediate network element. Thus, at each intermediate network element, the process polls that network element to discover the active cross-connects associated with the intermediate network element and thereby define that segments, e.g., which port connects the neighboring network elements. Segment information is then correlated to define each service leg. The service legs are then correlated to trace a service or circuit. A third loop, Loop 3 or step 622, is used only if new legs of the service are discovered while processing a saved connection termination point (CTP) . For example, if the process finds a connection termination point that was not previously logged, this connection termination point must then be traced to determine the segments comprising its service leg and thus discover its service leg. The trace route process 600 ends by returning an A and Z endpoint list(s), a route cross-connect list, along with any errors found in the trace. Alternatively, the cross-connect and endpoint information may be depicted in the form of network map or diagram.
In accordance with this aspect of the invention, the trace route process 600 is able to trace routes on all transport network technologies, including, but not limited to, SONET, DSn, synchronous digital hierarchy (SDH), WDM, and DWDM. With respect to SONET and SDH technologies, the trace route process 600 provides the capability to trace a route for a "sub-channel-rate" service which utilizes "tunnel" cross- connects. We refer to this feature as tunneling. Cross- connects for a sub-channel-rate service will be lower than the base timeslot rate. For example, for SONET, the base timeslot rate is STS1. A "sub-channel-rate" in this case could be VT1.5 (Virtual Tributary 1.5), since the STS1 must be channelized to handle the VT1.5. Similarly, for SDH, the base timeslot rate is AU . The structure and interfaces in accordance with an SDH network are defined in the ITU standard G.709, the disclosure of which is incorporated by reference herein in its entirety. A "sub-channel-rate" in the case of SDH would be VC-11 (Virtual Channel - 11) . A "tunnel" cross-connect is a cross-connect at a higher rate than the service(s) that traverses it. For example, while a VT1.5 service usually consists of a series of VT1.5 cross connects, it may be tunneled through one or more STS1 cross connects. The STS1 cross connects in this case would be considered the "tunnel"-cross connects. A number of VT1.5 services may traverse a single STS1 cross-connect. Services which start on, end on, or traverse a "tunnel" cross connect can be traced in accordance with this aspect of our invention .
In accordance with this aspect of the present invention, linear, point-to-point, broadcast, and multi-homed circuits can be traced. These circuits or routes traverse different network configurations such as rings, point-to-point or mesh configurations .
If a failure is encountered while tracing one leg of the service, the trace will attempt to trace additional legs, if they exist. Therefore, it is possible for a failed trace to return multiple errors.
Turning now to FIGS. 5B through 5B-5 there is shown a flow diagram in accordance with an embodiment of the trace route process of FIG. 5A. The process begins at step 605 with a user request comprising an endpoint network element's identifier (NE ID) and a connection termination point identifier (CTP ID) .
At step 610 the cross-connects for end point network elements is then discovered. As FIG. 5B shows step 610 includes the initial substep 610ι of determining whether each network element or device is already managed by the system 200. For each end-point network element managed by the system, the system is polled for their respective cross-connect information at step 6102. For any endpoint network elements that are not managed by the system 200, the system 200 attempts to discover the cross connects of that network element at step 6103. If the system is unable to discover cross-connects associated with an endpoint network element, line 6105, an error message is generated and stored to a return error list at step 640. Such an error message may indicate that the end-point network element, or any other network element, is not connected to the network. The process proceeds to step 622 or loop 3, which is described in detail hereinbelow.
If a cross-connect is found at step 6103, then the process continues to decision diamond 6108 to determine whether the cross-connect is carrying service and whether the network element is a WDM at step 610ιo. If the network element is not a WDM the process adds an error message to the return error list via line 6IO5 and proceeds to step 622 or loop 3. Note, however, that in an alternative embodiment if the ATOM module software module is included in the system 200, there is no need to invoke poll discovery, 6102, of the devices to trace a route. In such an alternative embodiment the topology may be assumed accurate and up-to-date since the ATOM module functions to autonomously track topology changes and update the appropriate databases that are a part of the system 200. The process would therefore proceed directly from step 6IO1 to step 6108 in such preferred embodiment. If the cross-connect is found and the equipment is a WDM the process proceeds to substep 610ι where the subchannel input levels are determined and saved at 6IO15. At the next substep 6102o an entry connection termination point list or entry list comprising the connection termination points and subchannels is built. Next, the trace direction with respect to each connection termination point of the entry list is determined at step 61025 as is shown in FIG. 5B-2, by checking whether each connection termination is to the Z-end or to the A-end, substeps 61027, 61029, and 6103ι, respectively. The process then proceeds to step 614 as shown in FIG. 5B-2, i.e., loop 1, to determine whether the cross-connect is already processed. This begins with a determination, as is illustrated via decision diamond 614χ, as to whether the cross-connects are in the route cross-connect list. For any cross-connect found in the cross-connect route list the process proceeds via line 6145 to add an error message to the return error list at substep 640 and continues to loop 3. However, for each cross-connect found to be not in the cross- connect route list that cross-connect is added to the route list at substep 6148. At 614u the from and to cross-connects are determined or parsed. At 614ι3 entry and exit cross- connects are then determined. At substep 61418 the process continues by selecting an exit connection termination point to trace and save the remaining connection termination points in an entry and exit list along with a subchannel levels field. In this way the process arrives at loop 2 or step 618 (see FIG. 5B-3) where the timeslots in the connection termination points exit lists are stored or retrieved for later use. At substep 6183 the connection termination points are traversed by searching for segments. In this way, each service leg is discovered one service leg at a time. This discovery process may be performed in accordance with substeps 6187, 618n, and 61815. In particular, at 6187 a parent connection termination point is retrieved. Each time a parent is found, the validity of the line rate of the segment is determined at 618χχ. If the line rate of the segment is found invalid, the process returns to retrieve a parent connection termination at 6187 and sets a line rate segment validity flag to false. If the line rate segment is determined to be valid, that segment is traversed to the opposite end line rate connection termination point 61815 and a line rate segment validity flag is not set to false. If there are no more parents and the line rate segment validity flag is set to false, the process proceeds to step 640 along line 610 . On the other hand, if there are no more parents, but no segments are found and the line rate segment validity flag is not set to false the process ends the current trace and updates the A or Z endpoint lists as is shown in substeps 6182o, 6182ι, and 61822- The process then continues to loop 3 or step 622. Where a line rate segment is found, as previously noted at 618i5, the segment is traversed to its opposite end line rate connection termination point. As shown in FIG. 5B-3, where a valid segment is found processing continues to either substep 61830 or substep 61833. Substep 61830 is used to find already provisioned connection termination points. Substep 61833 ends the trace for the current log. There are two conditions that allow processing to continue via substep 6I830. One condition is that a connection termination point rate is set to a predetermined value, lambda (which represents a wavelength or channel in a DWDM system) for example, and that the network element is managed by our system 200, represented as line 6I831. The other condition is that the cross- connection termination point rate is set to lambda and the equipment is a WDM or DWDM, represented as line 61832. If either of these conditions is met, then processing continues via 61830. In particular, the cross connects are discovered. If the equipment is identified as having an network element ID within the system 200 the network element cross-connections are polled at substep 6I835 (see FIG. 5B-5) . If the network element cannot be polled, then at substep 61837 associated provisioned connection termination points are searched for using the current timeslot sequence, the sub-channel level fields, and the equivalent cross-connect rate. Once the associated segments and cross-connects are found, the process returns via line 61838 to step 614 and continues processing as described above. If no associated segments and cross-connects are found, then a determination as to whether a tunnel cross-connect is used is determined at substep 6180. In determining whether a cross-connect tunnel is used a query is made as to whether the sub-channel level fields are populated at 61842- If the sub-channel level fields are populated, then a search is made for the provisioned connection termination points at substep 61843. If the search at substep 61843 is successful, then a tunnel would have been found and the process returns to step 614 and continues processing as described above. If it is determined at substep 61842 that the sub-channel level fields are not populated, then processing continues to check the validity of the capacity at substep 61846. Similarly, if a tunnel was not found at substep 61843 processing continues to substep 6186 to check capacity validity. If the capacity validity check proves false processing continues to step 640 via line 6I850.
On the other hand, if capacity validity check proves true then processing continues to substep 61833 which ends the trace for the current log. There are two other conditions that allow entry into substep 61833: (1) the connection termination point rate is not equal to lambda and the network element type is not set to WDM or DWDM, represented by line 61448; or (2) the cross-connection termination point rate is not equal to lambda and the system is not identified as within our system database, represented by line 6145o. In ending a trace log via substep 61833, the service end point is identified, 6I851, and the A and Z endpoint lists are updated, 6185 , with processing continuing to loop 3 or step 622 via line 61866-
At step 622 (FIG. 5B-5) the connection termination point exit list is checked and updated for each new cross connect found. In particular the following substeps are used to achieve this functionality. First, the exit connection termination point lists are checked to determine their fill status, step 622. If the connection termination point exit list is not empty, then at substep 6223 an exit connection termination point is selected from the exit list and processing returns to loop 2 or step 618. If, on the other hand, the connection termination point exist list is empty, then the fill status of the cross-connect termination entry list is determined as is indicated at substep 6225. If the cross connect termination entry list is found to be populated, the process reverses the trace direction by setting an entry connection termination point to an exit termination point, substep 6229, and returns to step 618. If the connection termination point entry list is empty, then a check is made, at substep 622χ5, for new connection termination point entry and exit lists. If a new list is found, processing returns to step 622, otherwise processing continues to step 627 where a return response is formed. In formulating a return response, current or existing errors are checked for on the return error list. If no errors are found the A and Z endpoint lists found along with the route connect lists are presented to the user as part of step 635. If errors are found then the errors, A and Z endpoint lists found, and the route connect lists are presented to the user as part of step 635. To further elucidate our novel trace route process, we will now describe the operation of the process in an exemplary network as depicted in FIG. 5C. The exemplary network of FIG. 5C depicts two ring networks that are connected via SN2, which is an OC-12 line. The first ring is comprised of network elements NE1, NE2, NE3 and NE4. The customer has purchased OC-3 service as indicated by dotted lines 670, 671, and 672 which are, respectively, connected to NE1, NE3, and NE4. The second ring is comprised of NE5, NE6, NE7, and NE8. In order to illustrate particular aspects of our invention as described above we assume that NE6 and NE7 have not been entered into our system and therefore are not managed by our NMS 200. In this exemplary embodiment, the user selects NE1 as the endpoint network element (NE) . The user is then presented with a selection of existing provisioned connection termination points (CTPs) , which will include STS1-1 on physical termination point-1 (PTP1), which in this example, has a (CTP-identifier) CTP ID of 1-1-1 (NE-PTP-Time Slot (TS) ) . The user selects 1-1-1.
Trace route is then called with the following information:
• NE ID = 1
• CTP ID = 1-1-1
• Subchannel Levels are blank Processing then continues as is shown via the following psuedo code, wherein the steps of FIG. 5B are included at beginning of each line:
Step 610: The cross connect in NE1 is found. Step 610ι4: Not Applicable (NA) Step 61020: Add CTP 1-1-1 to the Entry CTP List Step 61025: Set trace direction to "To Z End" since 1-1-1 is the "From CTP"
Step 614: Add NE1 CC to Route Cross Connect List Step 614u: NE1 CC has one "To CTP" - Timeslot
1 on PTP2 (CTP 1-2-1) . Since the CTP we entered NE1 on is the "From CTP", the "To CTP" will be treated as an Exit CTP. Traverse to Exit CTP 1-2- 1. Step 618: Set Current Timeslot Sequence to 1
(TS sequence on PTP2) .
Step 6183: Traverse Installed Line Rate Segment from PTP2 to PTP3.
Step 61830: Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 2-3-1. Loop to Step
614.
Step 614: Add NE2 CC to Route Cross Connect List
Step 614u: NE2 CC has one "To CTP" - Timeslot 1 on PTP4 (2-4-1) and an additional "From CTP" -
Timeslot 1 on PTP14 (2-14-1) . Traverse to Exit CTP 2-14-1, and add CTP 2-14-1 to Entry CTP List.
Step 618: Set Current Timeslot Sequence to 1 (TS sequence on PTP4) . Step 6183: Traverse Installed Line Rate Segment from PTP4 to PTP5.
Step 61830: Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 5-5-1. Loop to Step 614. Step 614: Add NE5 CC to Route Cross Connect List
Step 614n: NE5 CC has two "To CTPs" - Timeslot 1 on PTP6 (5-6-1) and Timeslot 1 on PTP9 (5-9-1) . Choose CTP 5-6-1 as Exit CTP to traverse, and add
CTP 5-9-1 to Exit CTP List.
Step 618: Set Current Timeslot Sequence to 1 (TS sequence on PTP6) .
Step 6183: Traverse Installed Line Rate Segment from PTP6 to PTP7.
Step 61830: Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 6-7-1. Loop to Step 614.
Step 614: Add NE6 CC to Route Cross Connect List
Step 614n: NE6 CC has one "To CTP" - Timeslot
1 on PTP8 (6-8-1). Traverse to Exit CTP 6-8-1.
Step 618: Set Current Timeslot Sequence to 1 (TS sequence on PTP8) . Step 6183: No segment found
Step 61830: NA
Step 61833: NA
Step 6I820: Since the Trace Direction is "To Z End", put NE6/CTP 6-8-1 in the Z endpoint list. Step 622: Since the Exit CTP List is not empty
(it currently contains CTP 5-9-1), Loop to Step 618 using CTP 5-9-1.
Step 618: Set Current Timeslot Sequence to 1 (TS sequence on PTP9) . Step 6183: Traverse Installed Line Rate Segment from PTP9 td PTP10.
Step 61830: Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 8-10-1. Loop to Step 614.
Step 614: Add NE8 CC to Route Cross Connect List
Step 614n: NE8 CC has one "To CTP" - Timeslot 1 on PTP11 (8-11-1). Traverse to Exit CTP 8-11-1. Step 618: Set Current Timeslot Sequence to 1
(TS sequence on PTP11) .
Step 6183: Traverse Installed Line Rate Segment from PTP11 to PTP12.
Step 61830: Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 7-12-1. Loop to Step
614.
Step 614: Add NE7 CC to Route Cross Connect List
Step 614n: NE7 CC has one "To CTP" - Timeslot 1 on PTP13 (7-13-1). Traverse to Exit CTP 7-13-1.
Step 618: Set Current Timeslot Sequence to 1 (TS sequence on PTP13) .
Step 6183: No segment found Step 61830: NA Step 6I833: NA
Step 6I820: Since the Trace Direction is "To Z End", put NE7/CTP 7-13-1 in the Z endpoint list.
Step 622: Since the Exit CTP List is empty, go on to next step. Step 6225: Since the Entry CTP List is not empty (it currently contains CTP 1-1-1 and 2-14-1) , change Trace Direction from "To Z End" to "To A End", loop to Step 618 using CTP 1-1-1.
Step 618: Set Current Timeslot Sequence to 1
(TS sequence on PTP1) .
Step 6183: No segment found Step 61830: NA Step 61833: NA
Step 6I820: Since the Trace Direction is "To A
End", put NE1/CTP 1-1-1 in the A endpoint list.
Step 622: Since the Exit CTP List is empty, go on to next step.
Step 6225: Since the Entry CTP List is not empty (it currently contains CTP 2-14-1), loop to
Step 618 using CTP 2-14-1.
Step 618: Set Current Timeslot Sequence to 1 (TS sequence on PTP14) .
Step 6I83: Traverse Installed Line Rate Segment from PTP14 to PTP15.
Step 61830: Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 3-15-1. Loop to Step 614.
Step 614: Add NE3 CC to Route Cross Connect List
Step 614!i: NE3 CC has two "From CTPs" - Timeslot 1 on PTP16 (3-16-1) and Timeslot 1 on PTP19 (3-19-1). Traverse to Exit CTP 3-16-1. Since this is part of the Entry CTP List loop, we need to create a new Exit CTP List and add CTP 3- 19-1 to it.
Step 618: Set Current Timeslot Sequence to 1 (TS sequence on PTP16) . Step 6183: Traverse Installed Line Rate Segment from PTP16 to PTP17.
Step 61830: Find Provisioned CTP at Current Timeslot Sequence of 1 - CTP 4-17-1. Loop to Step 614.
Step 614: Add NE4 CC to Route Cross Connect
List
Step 614ιχ: NE4 CC has one "From CTP" - Timeslot 1 on PTP18 (4-18-1) . Traverse to Exit CTP 4-18-1. Step 618: Set Current Timeslot Sequence to 1
(TS sequence on PTP18) .
Step 6183: No segment found Step 6183o: NA Step 6I833: NA
Step 6I820: Since the Trace Direction is "To A
End", put NE4/CTP 4-18-1 in the A endpoint list.
Step 622: Since the Exit CTP List is empty, go on to next step.
Step 6225: Since the Entry CTP List is empty, go on to next step.
Step 62215: Since a new Exit CTP List was created, loop to Step 622. Step 622: Since the Exit CTP List is not empty (it currently contains CTP 3-19-1) , Loop to Step 618 using CTP 3-19-1.
Step 618: Set Current Timeslot Sequence to 1 (TS sequence on PTP19) .
Step 6183: No segment found Step 61830: NA Step 61833: N^
Step 6I820: Since the Trace Direction is "To A End", put NE3/CTP 3-19-1 in the A endpoint list.
Step 622: Since the Exit CTP List is empty, go on to the next step.
Step 6225: Since the Entry CTP List is empty, go on to next step. Step 622ι5: NA
Step 627: Return success response with the following data:
• A endpoints - NE1/CTP 1-1-1, NE4/CTP 4- 18-1, NE3/CTP 3-19-1 • Z endpoints - NE6/CTP 6-8-1 and NE7/CTP
7-13-1
• Route Cross Connect List - NE 1 CC, NE 2
CC, NE 5 CC, NE 6 CC, NE 8 CC, NE 7 CC,
NE 3 CC, NE 4 CC
As the previous example shows, the system 200 may be used to trace a circuit or service in a network. In addition, the service traced may be more complex then a simple point-to- point linear service. Furthermore, the service trace method is able to discover each leg of a service. For example, two legs of service 670, which include the paths PTP1-PTP2-PTP3- PTP4-PTP5-PTP6-PTP7-PTP8 and PTP1-PTP2-PTP3-PTP4-PTP5-PTP9- PTP10-PTP11-PTP12-PTP13, may be traced in accordance with this aspect of the present invention. In accordance with another embodiment, the starting point (A- endpoint) and an ending point (Z-endpoint) devices may comprise network device 201 and another network device in network 206. The input information may then comprise cross- connect information device 201. The system then autonomously detects the other devices in the network by polling each such device to discover cross-connect and connection termination point information.
Autonomous Detection of Network Topology Changes In accordance with another aspect of the present invention, the system 200 may be equipped with the functionality to allow for augmentation of the network view. There are several instances that customers are currently faced with today regarding the management of their network. The system 200 has the ability to augment a stored network topology map and automatically extend services that traverse the network by intelligently recognizing service affecting events and accurately reflecting these events within the ETM network view . One such event occurs where a service has been "extended" when the network is augmented with new devices that are connected to existing portions of the network and services traverses the new devices.
Another such event occurs where a service is "rerouted." This indicates that the new route is terminated by the same devices but the path traverses through different network elements . Another such event occurs where a service is regroomed. This indicates that the new route is terminated by the same device as the old route but different cross connects are used because the timeslots have been changed. Yet another event occurs where a service has been "rehomed." This indicates that the original device is different than the new device, and the service has not been extended. Referring to FIG. 2C the topology abstraction layer 260 is shown as including an Active Topology Object Manager (ATOM) module 264. Broadly, the ATOM module 264 ensures that the topology stored in the system 200 represents, and is consistent with, the current topology of the actual network. In particular, the ATOM module 264 periodically polls the network elements and cross-connects managed by the system 200 and reconciles any changes that may have occurred on the network. Changes may also be autonomously detected through an event manager residing in the frame manager as discussed in relation to FIG. 4. Accordingly, the ATOM module 264 facilitates detection of service modifications such as network service extensions and service rerouting, regrooming and rehoming.
In accordance with this aspect of the present invention, the ATOM module 264 will periodically poll the network elements comprising a managed network to discover the cross-connect fabric of each network element. The cross-connect fabric is then checked against the stored or known information pertaining to each polled network element. If differences are detected, the system 200 then updates the network map to indicate such differences. Topology Link Validity Checks The network management system 200 may also be provided with the additional capability to verify a media, e.g., fiber, that connects two network elements therefore increasing the probability that the media entered is accurate. Such connecting media establishes a topology link for the network elements .
The links connecting two network elements in a transport network are not sophisticated. Accordingly, it is necessary to verify that the physical termination points (PTP) at two connected network elements is accurately tracked and reflected by the system too.
One approach to topology link validation is to identify a PTP from the neighboring network element PTP. For example, the path trace function available through the "Jl" byte in SONET, can be set to a specific value at one end of a topology link and read at the other end of the topology link. Another approach is to employ a physical test head at a location within the domain of the network managed by the system 200. The system would then design a route from the test over known links, traverse the link using the test head and looping back the test signal to see if the test signal returns to the test head.
A heuristic approach may also be used to check the validity of topology links. In this approach, the service tracing function is used to find topology links that do not have valid configuration.
As a general approach, the system 200 performs the verification by comparing the number of Connection Termination Points (CTPs) associated with each Physical Termination Point (PTP) at either end of the media connecting two network elements and noting the following two conditions: (1) each PTP on the network elements must have the number of CTPs; and (2) each corresponding CTP must be set to the same data rate, be in the same state (active or inactive) and claim the same units. If the CTP's do not match, the system 200 warns the user that the PTP's selected may not be the correct endpoints for the Topological Link. Route Design Turning now to FIG. 6A there is shown a flow chart for route design 800 in accordance with another aspect of the present invention. In accordance with this aspect of the invention, a service is provided on the system 200 that allows a user to design an end-to-end route for a service. In particular, and as shown in FIG. 6A, the route design process begins at step 810 when a user indicates the type of service that the user wishes to design by selecting the input route parameters from a pre-determined set of input parameters. Specifically, and as shown in FIG. 6B, the user indicates whether the route will be for a line-to-line service, step 813. If the route is for a line-to-line service the user is required to select, at step 816 input parameters from the following list of parameters: Transport Type (SONET, SDH, Lambda); Rate (OCn, OC1, EC3/STS3E, EC1/STS1E, DS3, DS2, DS1C, DS1A, El, DS1, STMn, STM1, STM1E, E4, STM0, E3, Lambda); A End and Z End network elements; Direction of Service (2 way, 1 way, not specified) ; Protection Class (Normal, Protected, Preemptable) . Once these parameters are selected for the line-to-line service the process loops to sub-process C, which continues the main process or method of FIG. 6A. Further in accordance with FIG. 6B, if the user does not choose to design a line-line-service then the user indicates whether the route is for a drop-to-drop service at step 817. If the route design will be a drop-to-drop service the user is then requested to input, in addition to the parameters requested at step 816, the A- End to Z-End ports, as is shown at step 820. As before, once the user defines or selects a service the route design process returns to C in FIG. 6A and continues on to step 830. In the event the user does not select the drop-to-drop option, the service selection process (810) continues to step 821 in FIG. 6B .
At step 821 the user is prompted to decide whether the service is for drop-to-drop with a higher line rate. If the user selects a design for a drop-to-drop with a higher line rate, then additional information is inputted at step 824. The additional information at step 824 comprises the A End to Z End timeslot identifiers. As before, once the user defines or selects a service the route design process returns to C in FIG. 6A and continues on to step 840. If the user still has not chosen a route design service to this point the user is then prompted to determine whether the user wishes to design a route which is a combination of a line to drop or drop to line route, at step 825. If a user has a specific service in mind not of the type disclosed above, then the user inputs any sequence of line-to-line and drop-to-drop parameters so as to have a line to drop or drop to line route design constructed at step 826. If the user does not wish to construct a route in accordance with the selection criteria available at step 825, then the process returns to D in FIG. 6A. Once a service is selected as described above with reference to FIG. 6A the process continues to step 840, where segments are selected automatically to construct the route as specified by the user via a route suggestion functionality operating in accordance with an aspect of our invention. A user may also use the route suggestion feature to obtain a list of routes that are compiled for the user.
The user has the option to provide the following route search constraints prior to the instantiation of the route suggestion method:
Include Location,
Include NE,
Include Subnetwork,
Include Segment Exclude Location,
Exclude NE,
Exclude Subnetwork,
Exclude Segment
A user can also navigate and select from the list of the suggested routes as is or select a list and modify it by deleting and inserting segments manually.
A user may also select a suggested route and alter the suggested timeslot of any one of the segments manually by selecting from a list of available timeslots for each segment. If user selects a different timeslot on a segment, the timeslots of all segments in the route that belong to the same subnetwork, as the segment on which the user made the timeslot change, will automatically change to the same timeslot . In accordance with step 840 a route or collection of routes are compiled by setting the following global properties: the maximum number of routes to be found; the initial duration of time to allow the system to find number of routes equal to the value for the maximum number of routes to be found (or at least one route), e.g., a tl threshold; and the total duration of time to allow the System to find number of routes equal to the value for the maximum number of routes to be found, e.g., a t2 threshold. With these parameters set, a Breadth First Search (BFS) is used to find the shortest route between one A end and one Z end in the cluster. Discard the route returned if it includes segments, NEs, subnetworks or locations that should be excluded. If the routes to be found are for routes with a single or multiple A-ends and single or multiple Z-ends, and a Protection Class of "Normal", "Protected" or "Preemptable" , then all available timeslots are found. If the routes to be found are for routes with multiple A ends or multiple Z ends, and a Protection Class of "Normal", "Protected" or "Preemptable", for each remaining end point (from above step) , using BFS, the shortest spur that meets up with the shortest route and all available Timeslots are found. If the Transport Routes to be found are for routes with a Protection Class of "DRI", BFS is used to search the cluster for subnetworks that are "DRIed" first, then the shortest "DRIed" route between one A end and one Z end is found. BFS is continued to find the next shortest route that spans the same DRIed subnetworks as the first one and all available Timeslots found. If no timeslots are found, a BFS is done for the next route found.
If timeslots are found, route is validated for continuous timeslot capacity within each subnetwork across the route. If continuous capacity is not available, BFS is done for the next route found. If continuous capacity is available, the NEs on the route are validated for capabilities to support the route. If NE capabilities do not support the route, BFS is done for the next route found. If NE capabilities support the route, the route is put on a list of suggested routes and BFS is continued for the next route.
BFS is continued until the maximum number of routes to be found, specified in corporate data, is reached or the total duration of time to allow the System to find number of routes equal to the value for the maximum number of routes to be found, specified in corporate data, is reached. BFS can be stopped when the initial duration of time to allow the System to find number of routes equal to the value for the maximum number of routes to be found, specified in corporate data, is reached and there is at least one route in the list of routes or can be continued until the total duration of time to allow the System to find number of routes equal to the value for the maximum number of routes to be found, specified in corporate data is reached.
Each route in the list is scored in a manner indicative of its relative desirability compared to other routes in the list. The list is sorted from highest to lowest score. The first route on the list is then displayed. Note too that a user may manually design a route by selecting segments from the graphical view or textually specifying NE Ids and Timeslot Ids of each segment, and adding each segment to the route under design. User selections are indicated both graphically and textually, regardless of the method of manual route design. Once the route segments are compiled and a route is designed in step 860, the process may continue to step 860 where a user can request validation of manually designed routes or routes selected from the list of suggested routes but later altered. Step 840 is an optional step which may or may not be required by certain users. When this is requested, the route is validated against disconnects, spurs and gaps. The segments of the route are also validated to provide continuous capacity within each sub-network that the route traverses. The NEs on the route are also validated for support of required route selection parameters.
Once route validation is completed the process continues to optional step 880 where a route may be reserved in accordance with another aspect of our invention we refer to as route reservation. Route reservation begins with the inputting of the expiration date for the reservation.
A reservation is then created and the route is reserved in topology. A "reservation created" notification task is created and assigned to a user id as a work item, based on the workflow settings. The system then generates a reservation expiration notification task and assigns it to the user id that created the reservation as a work item, 5 days before the expiration date. The reservation is automatically deleted on expiration date if not associated with a work order. Once a reservation is created the process continues at step 890 by updating or deleting a reservation. In addition a reservation may be released by un-reserving the route. Releasing a reservation removes the reservation from the reserved resources (ctps) but leaves them in topology. A user can delete the reservation manually (this removes the reservation and the reserved resource. The system deletes the reservation automatically at expiration date if the reservation is not related to a work order. The reservation expiration date may also be extended. In accordance with our invention many OAMP&P benefits are realized in the network. For example, because the network topology information is current and accurate, fault location becomes substantially more accurate. In addition, turning up of new services can be done much more timely; in particular, in the context of turning up new DSL customers our invention may reduce the time between service order and service delivery by orders of magnitude. Our invention also advantageously allows network operators and providers to break from old legacy systems such as TIRKS seamlessly in a cost efficient manner over any reasonably desired time period. Furthermore, our invention provides heretofore unheard of flexibility in the operation of the network. In particular, the DCP databases no longer need to be populated or maintained by the network operator, but may be populated by a third party, including the individual equipment suppliers. These and other advantages are realized in accordance with our invention.
Although the invention herein has been described with reference to particular embodiments, it is to be understood that these embodiments are merely illustrative of the principles and applications of the present invention. It is therefore to be understood that numerous modifications may be made to the illustrative embodiments and that other arrangements may be devised without departing from the spirit and scope of the present invention as defined by the appended claims.
The present systems and methods are applicable to software systems and processes for managing a telecommunications network and networks in general.

Claims

CLAIMS:
1. A system for autonomous topology discovery of a network including a plurality of network devices, comprising: a command translation module; a connection manager module for communicating with at least one network device on the network; a frame manager module coupled to said command translation module and said connection manager for managing a message flow between said command translation module and said connection manager module; and a device configuration profile database of abstract data objects representative of the network, said device configuration profile database coupled to said command translation module; and wherein said device configuration profile is updated autonomously in reference to changes affecting the devices in the network.
2. The system of claim 1, wherein said frame manager module further comprises means for encapsulating the message flow between said command translation module and said connection manager module.
3. The system of claim 1, wherein said frame manager module further comprises means for detecting events generated by the network element.
4. The system of claim 1 wherein said database includes connection termination point information relating to the structure devices .
5. The system of claim 1 wherein said network element configuration profile database comprises a plurality of databases.
6. The system of claim 1 wherein said command translation module comprises a software architecture including a topology abstraction layer, a device abstraction layer, and a service layer.
7. The system of claim 6 wherein said frame manager is coupled to said device abstraction layer and said topology abstraction layer.
8. The system of claim 7 wherein said service layer is coupled to said topology abstraction layer.
9. The system of claim 8 wherein said device abstraction layer includes a translation service.
10. The system of claim 7 wherein said topology abstraction layer is coupled to a network element configuration profile module.
11. The system of claim 6 wherein said service layer includes a discovery service.
12. The system of claim 6 wherein said service layer includes a cross-connect service.
13. The system of claim 6 wherein said topology abstraction layer includes a connection termination point module.
14. The system of claim 6 wherein said topology abstraction layer includes an active topology object manager.
15. A method for autonomously creating a network map of a transport network having a plurality of devices, said method comprising the steps of: inputting selected network data for at least some of the network devices residing on the network; processing the selected network data; and autonomously creating the network map based on said processed selected network data.
16. The method as claimed in claim 15 further comprising inputting a second set of selected network data and updating the network map based on said second set of inputted selected network data.
17. The method as claimed in claim 16 further comprising autonomously detecting topology changes in the network and updating the network map based on said detected changes .
18. The method as claimed in claim 16 wherein autonomously creating a network map further includes determining the equipment cross-connect matrix based on said network equipment identifier.
19. The method of claim 16 wherein processing comprises polling the at least some of the network devices to determine their cross-connect matrix information.
20. The method of claim 19 wherein processing further comprises retrieving business rules and command sets for creating the network map from a database.
21. The method of claim 19 wherein processing further comprises formulating threads for dispatch to the at least one of the network devices .
22. The method of claim 21 wherein dispatching includes translating each thread into a network specific thread.
23. The method of claim 22 further comprising formatting the frame specific thread for transmission over a network.
24. The method of claim 15 wherein processing comprises retrieving command sets for creating the network map and communication requirements associated with at least one of the network devices.
25. A method for tracing a service in a network, the method comprising: specifying an equipment identifier and at least one connection termination point identifier for at least one end- point network element in the network, and autonomously tracing a service in the network based on said equipment identifier and connection termination point identifier .
26. The method of claim 25, wherein autonomously tracing further comprises discovering at least one additional cross-connect termination point on the at least one end-point network element.
27. The method of claim 26, wherein discovering at least one additional connection termination point on the at least one end-point network element comprises polling the at least one end-point network element for active cross- connects .
28. The method of claim 27 further comprising determining a trace direction.
29. The method of claim 28 wherein said step of determining a trace direction comprises: checking the association of said discovered cross- connects; and setting said trace direction to indicate an A-end trace if said checking step indicates said discovered cross- connect is a FROM a cross-connect, setting said trace direction to indicate a Z-end trace if said checking step indicates said discovered cross- connect is a TO cross-connect.
30. A method of autonomously determining a communication route within the PSTN, the method comprising: inputting information about a starting point network device and an ending point network device within the PSTN; autonomously detecting a first network device including first cross-connection relating to the starting point device; autonomously determining a segment of the communication route between the detected first device and a further hardware device including further cross-connection information relating to the starting point device; and continuing to autonomously determined segments of the communication route between hardware devices including cross-connection information relating to the starting point device until the entire communication route is determined between the starting and ending point devices .
31 The method of claim 30, wherein autonomously detecting a first device comprises accessing a database having topology information about the PSTN to determine if information relating to the starting point and end point network devices is stored in the database.
32. The method of claim 31, wherein autonomously detecting further comprises determining cross-connect information relating to the starting point and end point devices including the first cross-connect information.
33 The method of claim 32, wherein autonomously determining the segments of the communication route comprises correlating said determined cross-connect information between network devices .
34. A computer-readable medium having computer-executable instructions for performing a method comprising: specifying an equipment identifier and at least one connection termination point identifier for at least one end- point network element in the network, and autonomously tracing a service in the network based on said equipment identifier and cross-connect termination identifier .
35. The computer-readable medium of claim 34, wherein selecting at least one input route parameter comprises selecting a starting-point device on the network and an ending-point device on the network.
36. A method of autonomously updating a database relating to the PSTN in response to a change in hardware status within the PSTN, the method comprising: detecting the hardware status change within the PSTN; autonomously generating information about the detected hardware status change; and autonomously updating the PSTN database by storing the autonomously generated information therein.
37. The method of claim 36, wherein detecting a hardware status change comprises detecting a change in the cross-connect settings of the hardware.
38. The method of claim 36, wherein detecting a hardware status change comprises detecting a fault occurring on the network.
39. The method of claim 36, wherein generating information about the detected hardware status change comprises transforming a message containing the hardware status change into an object-orientated data structure.
40. The method of claim 36, wherein autonomously updating comprises deleting information representative of cross-connect information from the database.
41. The method of claim 36, wherein autonomously updating comprises adding information representative of cross-connect information to the database.
42. A computer-readable medium having computer-executable instructions for performing a method comprising: detecting the hardware status change within the PSTN; autonomously generating information about the detected hardware status change; and autonomously updating the PSTN database by storing the autonomously generated information therein.
43. A method of autonomously creating a communication route within the PSTN, the method comprising: inputting data including a starting point and an ending point into a computer system; accessing a database including information about hardware devices within the PSTN; autonomously identifying pathways related to the hardware within the database; and autonomously creating a communication route between the staring and ending points by combining at least some of the identified pathways.
44. The method of claim 43, wherein accessing a database comprises accessing a database having topology information about the PSTN.
45. The method of claim 43, wherein accessing autonomously identifying pathways comprises determining cross-connect information relating to at least some of the hardware devices .
46. The method of claim 45, wherein autonomously creating a communication route comprises correlating the cross-connect information between hardware devices so as to identify a pathway between the starting point and ending point .
47. A computer-readable mechanism having computer-executable instructions for performing a method comprising: inputting data including a starting point and an ending point into a computer system; accessing a database including information about hardware devices within the PSTN; autonomously identifying pathways related to the hardware within the database; and autonomously creating a communication route between the staring and ending points by combining at least some of the identified pathways.
48. The medium of claim 47, wherein accessing a database comprises accessing a database having topology information about the PSTN.
49. The medium of claim 47, wherein accessing autonomously identifying pathways comprises determining cross-connect information relating to at least some of the hardware devices.
50. The medium of claim 49, wherein autonomously creating a communication route comprises correlating the cross-connect information between hardware devices so as to identify a pathway between the starting point and ending point .
PCT/US2003/010282 2002-04-03 2003-04-03 Intelligent network management system and method WO2003085543A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003224832A AU2003224832A1 (en) 2002-04-03 2003-04-03 Intelligent network management system and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US37009802P 2002-04-03 2002-04-03
US60/370,098 2002-04-03

Publications (1)

Publication Number Publication Date
WO2003085543A1 true WO2003085543A1 (en) 2003-10-16

Family

ID=28792026

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2003/010282 WO2003085543A1 (en) 2002-04-03 2003-04-03 Intelligent network management system and method

Country Status (2)

Country Link
AU (1) AU2003224832A1 (en)
WO (1) WO2003085543A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008110081A1 (en) 2007-03-14 2008-09-18 Huawei Technologies Co., Ltd. System, apparatus and method for tracking device
EP2107730A1 (en) * 2008-03-31 2009-10-07 Mitsubishi Electric R&D Centre Europe B.V. Method for determining to which resource among plural resources, elements of a group of elements have to be allocated
CN100592743C (en) * 2005-09-16 2010-02-24 中国科学院声学研究所 Operation supporting platform system for supporting stream media business
EP2341661A1 (en) * 2010-01-04 2011-07-06 Alcatel Lucent Neighbor discovery for Ethernet private line on user network interfaces
US8683460B2 (en) 2012-05-11 2014-03-25 International Business Machines Corporation Grandfathering configurations in a distributed environment
US11025340B2 (en) 2018-12-07 2021-06-01 At&T Intellectual Property I, L.P. Dark fiber dense wavelength division multiplexing service path design for microservices for 5G or other next generation network

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6374293B1 (en) * 1990-09-17 2002-04-16 Aprisma Management Technologies, Inc. Network management system using model-based intelligence
US20020052938A1 (en) * 2000-09-22 2002-05-02 Kyocera Corporation Network device management method, and network devices

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6374293B1 (en) * 1990-09-17 2002-04-16 Aprisma Management Technologies, Inc. Network management system using model-based intelligence
US20020052938A1 (en) * 2000-09-22 2002-05-02 Kyocera Corporation Network device management method, and network devices

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100592743C (en) * 2005-09-16 2010-02-24 中国科学院声学研究所 Operation supporting platform system for supporting stream media business
WO2008110081A1 (en) 2007-03-14 2008-09-18 Huawei Technologies Co., Ltd. System, apparatus and method for tracking device
EP2026503A1 (en) * 2007-03-14 2009-02-18 Huawei Technologies Co., Ltd. System, apparatus and method for tracking device
EP2026503A4 (en) * 2007-03-14 2009-09-30 Huawei Tech Co Ltd System, apparatus and method for tracking device
US8014294B2 (en) 2007-03-14 2011-09-06 Huawei Technologies Co., Ltd. System, apparatus and method for devices tracing
EP2107730A1 (en) * 2008-03-31 2009-10-07 Mitsubishi Electric R&D Centre Europe B.V. Method for determining to which resource among plural resources, elements of a group of elements have to be allocated
WO2011080042A1 (en) * 2010-01-04 2011-07-07 Alcatel Lucent Neighbor discovery for ethernet private line on user network interfaces
EP2341661A1 (en) * 2010-01-04 2011-07-06 Alcatel Lucent Neighbor discovery for Ethernet private line on user network interfaces
CN102687466A (en) * 2010-01-04 2012-09-19 阿尔卡特朗讯 Neighbor discovery for Ethernet private line on user network interfaces
KR101386502B1 (en) 2010-01-04 2014-04-17 알까뗄 루슨트 Neighbor discovery for ethernet private line on user network interfaces
US8683460B2 (en) 2012-05-11 2014-03-25 International Business Machines Corporation Grandfathering configurations in a distributed environment
US11025340B2 (en) 2018-12-07 2021-06-01 At&T Intellectual Property I, L.P. Dark fiber dense wavelength division multiplexing service path design for microservices for 5G or other next generation network
US11539434B2 (en) 2018-12-07 2022-12-27 At&T Intellectual Property I, L.P. Dark fiber dense wavelength division multiplexing service path design for microservices for 5G or other next generation network

Also Published As

Publication number Publication date
AU2003224832A1 (en) 2003-10-20

Similar Documents

Publication Publication Date Title
US7016379B2 (en) Integrated network element
US6223219B1 (en) Trail management across transport functionality of large and complex telecommunications networks
US7352758B2 (en) Dynamic bandwidth management using signaling protocol and virtual concatenation
US20010033550A1 (en) Physical layer auto-discovery for management of network elements
US7991872B2 (en) Vertical integration of network management for ethernet and the optical transport
US5796723A (en) System and method for end-to-end threshold setting
US5848244A (en) System and method for time-based real-time reconfiguration of a network
JPH0865384A (en) Operation of network management system
US6990517B1 (en) Synchronization modelling using templates and network management system
JPH10504427A (en) Telecommunications system
JP2006506903A (en) Connection management system and graphical user interface for large-scale optical networks
CA2092872C (en) Message routing for sonet telecommunications maintenance network
US7170851B1 (en) Systems and methods for automatic topology provisioning for SONET networks
US7002907B1 (en) System and methods for automatic equipment provisioning for SONET networks
US7058012B1 (en) Systems and methods for automatic end-to-end path provisioning for SONET networks
US5768255A (en) System and method for monitoring point identification
US6721735B1 (en) Method and apparatus for synchronizing databases in a network management system
WO1998028875A2 (en) System and method for message-based real-time reconfiguration of a network
Ellanti et al. Next generation transport networks: data, management, and control planes
WO2003085543A1 (en) Intelligent network management system and method
CN103108347A (en) Association alarm method and association alarm device of wired network and wireless network
US20030158925A1 (en) Management of communications networks
US7680033B1 (en) Network manager circuit rediscovery and repair
Cisco Managing and Configuring Network Elements
Xu et al. Generalized MPLS-based distributed control architecture for automatically switched transport networks

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP