This invention relates generally to verifying a description of a network and, more particularly, to confirming that the description of the network is consistent with communication paths of the network.
Networks, such as communication networks, transmit various types of data concurrently, such as text, voice, video and other multimedia files. Communication networks are becoming increasingly complex, especially due to their increasing speeds of operation, the number of interconnected devices and the formation of large networks from sub-networks. Another factor increasing the complexity of communication networks is the layered nature in which a logical link at one technological level is provided as a service by a different technology level. For example, a web browser process might establish a TCP (Transmission Control Protocol) connection to a server process; the connection appears to the two processes as a link. In fact, data sent across the connection traverses an underlying connectionless IP (Internet Protocol) network; a link in the IP network might be provided by a complex hierarchy of connection-oriented ATM (Asynchronous Transfer Mode), SONET (Synchronous Optical Network), and DWDM (Dense Wavelength Division Multiplexing) networks. The layering complexity of networks can only be expected to increase in the future, with the advent of wireless links, virtual private networks and overlaid protocols, such as SIP (Session Initiation Protocol).
Computer tools may be used to design, inventory, analyze, optimize and test networks. These computer tools need a language to describe networks, and fundamental to any such language is a model of network topology, which is a set of links and connections in the network. Conventional computer tools do not permit a uniform network description across multiple levels. Each specific network technology typically has an associated description provided by a standards document; these technology descriptions are usually very detailed and not easily abstracted. Conventional computer tools may use a specific model of network topology; however, the definition of a term in the model of one tool may not match the definition of the same term of another tool. This inconsistency requires a detailed analysis of the semantic model to transfer data between tools.
Thus, conventional approaches do not provide models that can uniformly describe networks across multiple levels. Therefore, it would be an advancement in the art to be able to efficiently confirm that a network is operating according to its specifications.
Generally, a method and system are disclosed for verifying a description of a network represented by network map data. Logical links of a network are accessed and a determination is made whether each logical link corresponds to a network communication path. The network communication path is represented by physical link data, connection data, and adapter data.
If the logical links correspond to the communication paths, an affirmative indication is generated. If the logical links do not correspond to the communication paths, a negative indication is generated. These indications can be provided to an output module.
A more complete understanding of the present invention, as well as further features and advantages of the present invention, will be obtained by reference to the following detailed description and drawings.
The present invention provides an algorithm to verify a description of the topology of a network. This verification is a pre-condition for many algorithms that manipulate such descriptions, including algorithms that perform network optimization and reorganization, summarize traffic, compute reliability, detect recent changes and analyze alarms. As discussed further below, the topology of the network is described in a language, such as, for example, NetML, which is a language for recording the physical and logical topology of a communications network. NetML is an XML-based language that is applicable across multiple network levels and to a variety of network technologies. Fundamental to NetML is a formal topology model that includes network map data, which is, for example, an abstract computer representation of a network. The network map data includes: physical map data, which represents a set of communication paths; logical map data, which represents a plurality of logical links; and binding data, which represents an association, relationship or correlation between the physical map data and the logical map data.
A verification algorithm, which may use NetML syntax, validates the network map data by establishing that each logical link of the logical map data corresponds to a communication path of the physical map data. The physical map data is analyzed to determine communication paths using physical link data, which is representative of an association of two physical end ports, adapter data, which is representative of adapter type and layer, and connection data, which is representative of an association of two physical ports of a physical link or a physical port of a physical link and a port of an adapter. An indication of whether each of the logical links corresponds to a communication path is provided to an output facility, such as a user interface or display device. If each logical link of the logical map data corresponds to a conductive path, the network map data is consistent, or valid; if not, the network map data is determined to be inconsistent, or invalid, and thus does not accurately represent the network it models.
Server 106 and facilities 112(a) through (n) (generally referred to herein as facilities 112) are typically servers, or other computing devices, with memory and processing capability, coupled to network 108 via associated bi-directional transmission media 136 and 132(a) through (n), respectively. The CPE 150(a) through (n) (generally referred to herein as CPE 150) may be, for example, telephone devices, PBX (private branch exchange) equipment, facsimile machines, scanners, or any other equipment arranged to be connected to network 108, via associated interconnection media 152(a) through (n) (where n is any suitable number) (generally referred to herein as interconnection medium 152). The interconnection medium 152 are, for example, wired or wireless connections. The user may access remote server terminal 106, facilities 112 and CPE 150 using software, such as an applet, operating among the terminal 102, the network 108, and the server terminal 106, facilities 112 and CPE 150.
Terminal 102, which is coupled to network 108 via interconnection medium 142, may be, for example, a personal computer (PC), hand-held device (e.g. PDA), or other processing module, as discussed further below in conjunction with
An abstraction, or description of the network topography, also referred to herein as network map data, or a network map, describes network connections, and may be stored at a remote location, such as server terminal 106 and accessed by terminal 102. One way to process the network map data is to download it to terminal 102, process the data and store an indication either at terminal 102 or at a remote location.
The terminal 102 can access a verification algorithm that processes the network map data to determine whether it is valid. For example,
The processor 226 may be used to access and process the data stored in memory 216.
The memory 216 typically includes read only memory (ROM) (not shown), random access memory (RAM) (not shown) and an operating system (not shown). Memory 216 stores the network map data 218 and verification algorithm 800. Network map data 218 includes logical map data 301, physical map data 302 and binding data 700. Physical map data 302 includes physical link data 400, adapter data 500 and connection data 600. The components of memory 216 are discussed below in conjunction with
While
Although only one central processing unit (CPU) 226 is shown in
In order to verify the network map data, it is necessary to describe the network topology. NetML is one language that can be used to describe the topology of a telecommunications network, which includes physical links, logical links, ports and internal cross-connects. NetML is an interchange language that can conform to a particular XML schema. To promote interoperability of tools, NetML is based on a model that is independent of any particular technology and applicable to most common technologies. NetML assigns physical links a type, or layer, which characterizes the format of the data. NetML identifies a link independent of network hierarchy and uniformly incorporates both circuit-switched networks, such as SONET, and packet-switched networks, such as IP and Ethernet, allowing descriptions of communications paths that traverse both packet and circuit switched networks. NetML also provides an XML representation that allows interchange of network descriptions among computer tools.
Logical map data 301 shows logical link 332, which is a representation of a communication path from logical link port 330 to logical link port 331. Typically, logical map data 301 includes a plurality of logical links; however,
Physical map data 302 includes physical link data, adapter elements and network elements. These components are discussed in more detail below.
Physical Link Data
Generally, physical link data includes one or more physical links. A physical link represents an ability to transmit data from one place to another and has two ports, one being a start port and the other being an end port.
A physical link is characterized by its layer. A layer is an aggregate set of conventions required to interpret the information flowing on the link as a bit stream. The layer may include, for example, specifications for bandwidth, bit encoding scheme, error correction codes, signaling protocol, framing format and header information.
As shown in
Physical links and ports may be interpreted concretely, as physical objects. Physical links 309 and 329 could be, for example, copper or fiber cables and ports 307, 308, 321 and 322 could be physical connectors at the end of the cable. Also, physical links 309, 329 could be wireless connections and the ports 307, 308, 321 and 322 could be connectors attached to antenna circuitry.
A further discussion of physical link data is provided in relation to
Adapter Elements
As shown in
The adapter elements are configured to perform adaptation or conversion between layers of a network. Each adapter has an associated adapter type. The adapter type determines the layer and label of a host port and a sequence of layers and labels for guest ports. An adapter is labeled with its type, and the layers and labels of its ports must agree with the corresponding layers and labels in the type for the adapter to perform adaptation operations.
For example, an adapter that has a single guest port and a single host port causes any data stream of the appropriate layer to be injected into the guest port where it is adapted (converted) to the layer of the host port and then ejected. An adapter that has several guest ports and a single host port causes the data streams injected into the guest ports to be multiplexed together and ejected from the host port. Adapters are bi-directional, so they can be used to convert data back from the host layer to the guest layer or layers.
A communication path can be established by injecting data into a guest port of an adapter, the adapted data is ejected from the host port, traverses a link (or, more generally, another communication path) to another adapter host port, where it is then de-multiplexed, or “unadapted,” and ejected from the guest port with the same label as the first guest port. The adapter types and guest port labels and layers must match in order to establish a communication path. The adapter type determines the layer of a host port and a sequence of layers for guest ports. An adapter is labeled with its type and the layers of its ports must agree with the corresponding layers in the type.
A further discussion of adapter data is provided in relation to
Network Elements (Connection Data)
Network elements, 310323 and 336, also referred to as nodes herein, show that connection data can be generated by compiling, or combining, a plurality of links and associated ports, and/or portions of a plurality of links and associated ports, together. Examples of connection data representing a communication path are: port 306 and port 307; port 308 and port 315; port 320 and port 321; and port 322 and port 328.
A further discussion of connection data is provided in relation to
The physical map data 302, which may be represented as NetML, may include a plurality of network layers, such as, for example, SONET, SDH (Synchronous Digital Hierarchy), IP and ATM. As discussed above, a link or port is characterized by its layer, which is the relevant set of information required to characterize the data flowing on a link. The layer may include specifications for bandwidth, bit encoding scheme, error correcting codes, signaling protocol, framing format, header information or other information and may be viewed as an aggregate.
For example, a sequence of adaptations allows a layered interpretation of the data actually transferred over a plurality of physical links. Data at a first port may be IP; at a second port the data can be interpreted as IP over ATM; and at a third port, the data can be interpreted as IP over ATM over SONET. The data at a fourth port can be interpreted as the direct encapsulation of IP over SONET.
While the example of
As shown in
As shown in
Binding data 700 shows that ports 330 and 304 and ports 331 and 325, respectively, are bound. As shown in
Data from port 317 is multiplexed by adapter 316 and ejected from host port 320. Connection data 600, shown in
Generally, verification algorithm 800, which is described using examples used in
A communication path between two ports X (304 of
Step 802 begins the algorithm for verifying whether there is a communication path from a port X (304 of
If step 846 determines that port N is not port Y (port 325 of
If decision step 852 determines that there is not another port connected to port N, “no” line 854 leads to step 862, which determines that a path does not exist, and the logical link does not correspond to a communication path and, therefore, the network data is not valid. Line 864 leads to step 868, which establishes a reason for the invalidity. The reason generated may identify one or more logical links that do not correspond to a communication path. This reason can identify whether the failure was attributed to link data, connection data, adapter data or a combination thereof. The step of generating a reason is optional and can be omitted.
Step 870 stores reasons for the failure. Step 872 generates an accumulation of invalid logical links, such as a manifest, or record. This manifest may include the reasons for the invalidity. As a further embodiment, the manifest can optionally be transmitted to an output module or facility.
Step 874 generates a response, or negative indication, or alert, reflecting the inconsistency. This negative indication may be output to a user device, or display device or may be stored in a remote or local memory. End step 892 ends the algorithm.
Returning to step 804, if port X (port 304 of
When all of the logical links of a logical map have been validated, or verified, by establishing that each logical link represents a communication path, a match indication is generated. This affirmative indication may be output to a user device, or display device or may be stored in a remote or local memory. If each of the logical links is not valid, the network map data is not valid.
While
As described above, layers and adapter types can be discriminated in the network and these layers and types may be preserved during the manipulations of the present invention.
It is also a further embodiment of the present invention that the verification algorithm determines a communication path corresponding link as efficiently as possible. For example, as soon as a logical link is verified, processing terminates for that logical link.
As is known in the art, the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. The computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk.
It is to be understood that the invention may be practiced with other computer system configurations, including, for example, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronic devices, network PC's, minicomputers, mainframe computers, and other devices with processing capabilities. The embodiment may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
It is to be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of this invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention.