Patent Application
20060221865
Communications networks generally comprise two or more nodes, such as a computer or a router, connected together by a series of communications links and network elements which themselves may be connected in a variety of ways, including via electrical and fiber-optic cables. A cable carries one or more connections, or communications links, between two adjacent network elements, and a network path within a network is defined by a connection between two end nodes. Network elements located along the network path between the two end nodes provide the interconnection of individual connection segments, the sum of which compose the entire end to end connection between end nodes.
Once established, transport network topologies have traditionally been static and seldom changing. This semi-permanence arises from a number of factors. From an operations aspect, the provisioning of transport lines and paths and supporting databases have traditionally been triggered from a centralized network management framework using centralized polling techniques. These centralized operations approaches add complexity in that these network management platforms must contain knowledge of network topologies across differing layers of the transport hierarchy. Modifications to existing topologies require much analysis, planning and possibly changes to the management platforms themselves, adding even more complexity. This all results in additional time and effort, contributing further to the static nature of transport networks.
For example, equipment orders are placed and deployed based on network engineering planning functions and the resulting provisioning of the management systems' logical view of engineered network topology. Traditionally, once their supporting transport facilities are physically equipped (or even before becoming equipped), transport lines and paths are provisioned and placed in-service via management elements (i.e., Element Management Systems/Network Management Systems) residing in the management plane. As a drawback, this static provisioning approach offers up the possibility of the management plane's topological viewpoint of these transport resources becoming misaligned with the actual connectivity of these same transport resources in the transport plane. This viewpoint may result in “orphaned” equipment deployed to the field that may not be used or may be underutilized in actual link connectivity.
In terms of physical connectivity, transport lines and paths have traditionally been connected on a semi-permanent basis either directly between transport/switching nodes or through cross connect and multiplexing platforms. In the latter case, this connectivity has been directed via traditional operations procedures rooted in the management plane.
Management and control plane domains may encompass one or more hierarchical layers of the transport plane. A control channel is a logical channel that carries network information rather than the actual data messages transmitted over the network. Connections created by management/control plane actions within a serving transport layer (e.g., the Optical Carrier level-n (OC-n) line layer) may in fact be advertised and used as links for a client transport layer (e.g., the Synchronous Transport Signal (STS) path layer).
Typically, relationships between management and control actions directing connectivity within and between transport layers must interoperate with a fairly high degree of coordination and synchronization. This tends to introduce a fair degree of dependence and coupling in the sequencing and execution of management and control actions pursuant to connection establishment and verification functions. The coordination of these actions is typically dependent on the proper deployment of equipment and personnel encompassing the correct skill sets, to the proper locations, in the same timeframes. The failure in any of these regards represents a weakest link scenario with a high likelihood of wasted time and resources, additional costs, and longer service activation times.
Adding even more complexity are network service providers' requirements in the form of multi-vendor interoperability. New service deployments requiring the involvement of and interaction between multiple layers of the transport hierarchy typically dictate the requirement for interoperability between multiple vendors' implementations of their respective elements of transport, management, and control planes. These requirements may dictate interoperability of multiple vendors' management and/or transport planes either within the same layer (intra-layer interoperability) or between layers (inter-layer interoperability) of the transport hierarchy. With the introduction of additional transport layers (e.g., the photonic layer) and associated management plane(s), along with the dynamics introduced by control plane capabilities, the complexities of multi-vendor interoperability are magnified even further. Aside from the technological interoperability complexities, the alignment of product releases across multiple vendors' product roadmaps creates additional complications. Again, these complexities translate to additional time and resource commitments, adding even more to the stratification of transport networks, which weighs into longer deployment times of new offerings from network service providers.
The introduction of a number of technologies, such as Wavelength Division Multiplexing (WDM), optical switches, mesh restoration, and control planes, have tended to skew transport network topologies towards the more dynamic end of the spectrum. This paradigm shift has tended to magnify and raise in importance a number of issues that have not been as critical in the more traditional, static approaches to transport networking. Aspects of the present invention renders assistance to the control and management planes in support of improved robustness, autonomy, and performance requirements dictated by the new transport networking dynamics.
One embodiment of the present invention provides a method and system for automatically discovering transmission links and network paths among network elements in a communications network by detecting and validating proper connectivity between communications ports residing on network elements. This embodiment uses in-band communications in the communications network, initiated by the network elements; along with the correlation of link related attributes of the communications ports to automatically discover and validate physical connectivity between the network elements. Once physical connectivity is thus discovered via network elements within the transport plane, further correlation and validation of link related attributes and supporting databases can be initiated and carried out in either the control plane or the management plane. The method and system may also include the establishment of control channel adjacencies, also initiated from either the control plane or the management plane. By using these methods, a network service provider can update databases and manage network connectivity for its customers.
Another embodiment of the present invention provides a method and system for establishing control channel adjacencies, or management connectivity in a network, by sending an in-band signal from a network element over a network path using dedicated communications overhead of the network path. The signal contains an initiation message that indicates a unique identifier of the originating network element. A management element receives the signal and processes the initiation message to make a connectivity determination to the originating network element. Based on the connectivity determination, a connection between the management element and the remote access device is established.
The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
A description of preferred embodiments of the invention follows.
The principles of the present invention enable automatic discovery of various levels of transmission links and paths between network elements in communication networks by employing two procedures: port identification and link correlation. In some circumstances, a third procedure, referred to as control adjacency, may also be employed. Each of these three procedures is discussed in detail below.
Embodiments of the present invention render assistance in the de-coupling of management plane and control plane actions pursuant to the management and control of client/serving transport layers. They allow for the autonomous discovery of new links within a serving transport layer that can then be offered up to a client transport layer for advertisement there. As an example, when an Optical Carrier-level n (OC-n) link is completed between two network elements by virtue of connection across an optical fiber switching node, that OC-n link will be discovered via automated link discovery procedures which in turn provide notification of that link's existence to an Automatically Switched Optical Network/Generalized Multi Protocol Label Switching (ASON/GMPLS) based control plane. The control plane can then advertise this OC-n link thus enabling Synchronous Transport Signal (STS) connectivity across that OC-n link. That subsequent creation of these STS connections may in turn cause STS paths to be automatically discovered by other STS path terminating transport nodes so that these STS paths can in turn be advertised to the control plane thus enabling Virtual Tributary (VT) connectivity across any of these newly discovered STS links.
Port identification procedures 150 execute entirely within the transport plane 100 and are triggered by the communication of port identities across a transport link's in-band “discovery channel” 110 between network elements connected by that link. The exchange of port identification information between the network elements constitutes a remote port identification event (also referred to herein as a “port event”) to be conveyed via one or more notification messages 115 to either control elements 201a and 201b (collectively 201) residing within the control plane, management element 301 residing within the management plane 300, or both.
Control adjacency procedures 250 are responsible for the establishment of all required communications channels needed in either the control plane 200 and/or management plane 300 so that link correlation procedures 350 can execute.
Link correlation procedures 350 execute in either the control plane 200 or management plane 300 subsequent to the establishment of appropriate control adjacencies. Link correlation procedures 350 correlate and negotiate link related attributes to the point of agreement or denial resulting in either link discovery or various link attribute mismatch events being generated. The successful completion of link correlation procedures 350 means that a valid link has been discovered between the local and remote network elements 101, and notification of this link may now be placed towards the management 300 and control planes 200 for utilization in their respective connection provisioning/switching functions. Link correlation procedures 350 operate and communicate via messages over a control channel 210 as established by control adjacency procedures 250.
Due to the decreased dependencies discussed earlier, the present invention assists in the reduction of inter-layer interfaces and execution sequencing dependencies of management and control actions and events across client/serving transport layers 100. As such, vendor X's management 300 and control planes 200 administering or controlling any given serving transport layer (e.g., the OC-n line layer) may operate fairly independently of vendor Y's management 300 and control planes 200 that administer or control a client transport layer 100 (e.g., the STS path layer). This de-coupling is enabled by allowing the client transport layer 100 to discover needed link resources set up by its serving transport layer 100 whenever that layer completes its control 200 and management plane 300 activities needed to establish and validate the serving link. This also provides customers greater flexibility in terms of network operations and greater freedom to mix and match different vendors, as deemed necessary.
Rather than using a management element to dictate the transport plane's 100 topology from the management plane 300, the present invention facilitates a dialog between the management 300 and transport planes 100 in determining and aligning their respective topological views. With link discovery notifications emanating from the transport plane 100, the management 300 and control planes 200 can make the determination to update their topological viewpoints to reflect these new associations or conduct additional operational actions to bring the transport plane 100 and the management 300/control planes' 200 topology views into alignment. With improved performance and scale, the embodiments of the present invention can be a beneficial tool to be used in the reduction/closure of the topology mismatch window induced by the increased dynamics of transport networks.
Port Identification Procedures
The combination of a local network element's local port identity and a remote network element's remote port identity provides an informational context of a transport link that connects a local network element 101a and remote network element 101b. The local port identity maintained by a network element 101a is communicated across the associated port's discovery channel 110 supported by the communication links 108 for detection by a remote network element 101b connected to that link via its own local port. The discovery channel 110 is a communication channel adapted for use in according to the principles of the present invention to transport messages carried in-band on the link to be discovered in the process described herein. A number of port identification procedures deal with the communication and detection of port identification attributes between network elements across the discovery channel 110 as well as the notifications emanated towards the appropriate control and management plane elements of this information.
The discovery channel 110 is used by autonomous link discovery procedures to communicate port identities via a “discovery message” 124 and an associated “discovery response” 134 between the endpoints of the link under discovery as shown with reference to
OC-n Line: section trace overhead
STS-n Path: path trace overhead
Note that these are offered as examples only of possibilities underlying the physical layer of the discovery channel 110 as might be implemented for OC-n Line and STS-n Path links. The underlying physical layer of the discovery channel 110 is based on an in-band mechanism utilizing some portion of the bandwidth of any given link 108 connecting two network elements 101 so as to establish communication continuity across that link 108. With the discovery channel 110 being in-band, the arrival on any given network element of a message emanated by another network element across the discovery channel 110 implies link connectivity between the sending and receiving network elements 101 (e.g., network elements 101a, 101b respectively).
The discovery message 124 and the associated discovery response 134 are used to convey various local and remote port identities between the two ports terminating a link 108. The discovery message 124 contains the “local port” ID of the transmitting network element. The discovery response 134 contains the “local port” ID of the transmitting network element and also “observed remote port” information that is updated at network elements to take the value of “local port” ID information received in discovery messages 124 or discovery responses 134. As such, the transmission of a discovery message 124 and reception of a discovery response 134 acts as the triggering mechanism for a number of functions that keep the current values of various port identification attributes up to date between the two endpoints of a link.
If a “link discovery enabled” attribute is set, a Remote Port Detection (RPD) procedure 120 triggers upon the reception of either a discovery message 124 or a discovery response 134 containing a validly formatted “local port” ID parameter. The value of that received “local port” ID becomes the current value of the receiving port's “observed remote port” ID attribute value. The “link discovery enabled” attribute must be set to “enabled” before discovery message transactions are processed further.
A discovery response 134 includes the transmitting network element's “local port” ID, as well as the “observed remote port” ID. Upon receipt of a discovery response 134 containing a validly formatted “observed remote port” ID parameter, a network element updates its own “observed local port” ID based on the received “observed remote port” ID. Note that if prior discovery message(s) 124 have not been received across the local port, then the observed remote port ID attribute value should be set to NULL.
For example, with respect to
A Bidirectional Connectivity Validation (BCV) procedure 130 verifies that the transmit fibers and receive fibers are physically connected to the same pair of ports. If so, then the values of the local port's “local port” ID and “observed local port” ID attribute values are in agreement. If not, then a “bidirectional mismatch” event is detected as shown in reference to
If a bidirectional connectivity mismatch event is not detected by the BCV procedure 130, a Port Attribute Correlation (PAC) procedure 140 verifies that expected (i.e., provisioned) versus observed port attribute values are in agreement. If they are not, then the appropriate mismatch notifications are issued as shown with reference to
In
Any given port on a multi-rate port card can terminate and frame to multiple native SONET/SDH line rates (OC-3/STM-1, OC-12/STM-4, OC-48/STM-16, OC-192/STM-64). In order for the remote port identification procedure to function, multirate port cards automatically cycle through the native rates supported by any given port (OC-3, OC-12, OC-48) until framing is achieved.
In some circumstances, it is possible to provision the expected line rate on a per port basis for multi-rate line cards. An expected line rate mismatch standing condition arises when the port's observed line rate and expected line rate attributes do not agree. The detection of this condition results in an expected line rate mismatch event notification being issued to either the control plane 200 and/or management plane 300 destinations as determined by a notification destinations attribute value.
If, as in
Link Correlation Procedures
After port identification procedures successfully verify that the expected and observed port information are in agreement, link correlation procedures 350 perform the correlation and/or negotiation of link related attributes between the local and remote ports. Link attributes may be determined automatically via detection of new equipment (i.e., the observed link attribute values) or manually via provisioning actions (i.e., the expected link attribute values) of associated attribute values residing in the management, control, or transport planes. The determination of whether the control plane resident or management plane resident attributes are correlated against the transport plane resident attributes is a function of whether the link correlation procedures 350 are executing in the control or management planes. Any mis-comparisons between observed and expected link attribute values may be negotiated between the link endpoints. Non-negotiation of mis-compared or missing link attributes results in appropriate link attribute mismatch conditions being reported via notifications 210 to management elements 301 residing in the management plane 300 for resolution by other means (e.g., management/maintenance actions).
The successful correlation of all link attributes means that the link's related attributes are conducive to each other, and that the newly discovered link is worthy of bearing service. At this point, management elements 301 residing in the management plane 300 and/or control elements 201 residing in the control plane 200 are made aware of the newly discovery link via a “link discovered” event notification.
As an example, in the case of the control plane, the link discovered event notification would be an enabler for the advertisement of the newly discovered link to the routing functions performed via control elements 201.
The link correlation procedures 350 are triggered by a “remote port detected” event notification 126 from the PAC procedure 140. If a control channel 210 spanning an established control adjacency does not exist with the remote control element of the “remote port detected” event notification 126, then control adjacency procedures 250 must first be executed to establish such a control adjacency and control channel 210 as discussed-later in the example scenario of
A Transport Attribute Correlation (TAC) procedure 220 verifies that the values of the transport plane-resident attribute values for the local and remote ports are in agreement with each other. Towards this end, the TAC procedure 220 will execute a number of “attribute request” 214—“attributes response” 216 and “query request” 224—“query response” 226 transaction(s) to both network elements 101A, 101B anchoring the endpoints of a newly detected link. Corresponding port attributes retrieved from the two network elements 101A, 101B will then be compared in a “compare attributes request” 236—“compare attributes response” 246 transaction for any potential mismatches. If any mismatches are found, then a “transport attribute mismatch” condition exists and the “transport attribute mismatch” event notification 228 will be transmitted to a management element 301 as shown in
If a “transport attribute mismatch” condition is not detected by the TAC procedure 220, then an Operations Attribute Correlation (OAC) procedure 230 verifies that the values of the transport plane resident local and remote ports attribute value obtained by the previously executed TAC procedures 220 are in agreement with similar local and remote port attribute values residing in the control and/or management plane. The OAC procedure 230 executes a number of “control query request” 256—“control query response” 266 transaction(s) to a peer control element 201. Corresponding port attributes retrieved from the peer control element 201 are then compared for any potential mismatches. In this way, inconsistencies in configuration of expected values of attribute values residing in the control 200/management planes 300 and similar attribute values residing in the transport plane 100 are proactively unearthed prior to a link being placed into service. If any mismatches are found, then a “control attribute mismatch” standing condition exists and the appropriate “control attribute mismatch” event notification 238 will be transmitted to a management element 301 as shown in
The successful correlation of all link attributes via the link correlation procedures 350 specified above means that the link's related attributes are conducive to each other, and that the newly discovered link is worthy of bearing service. At this point, the appropriate management 301 and/or control 201 element(s), are made aware of the newly discovery link via a “link discovered” event notification 218.
Control Adjacency Procedures
If a control channel does not already exist between the control elements 201 or management elements 301 associated with the endpoints of a newly discovery link, then a control channel 210 along with any supporting control adjacencies must be established. Control adjacency procedures 250 are responsible for the establishment of all required control adjacencies and the control channels 210 that traverse the control adjacencies. These control channels are needed in either the control and/or management planes so that link correlation procedures 350 can execute.
Link correlation procedures 350 may be allocated for execution on either control elements 201 residing within the control plane 200 or management elements 301 residing within the management plane 300. This implementation choice dictates when control adjacency procedures 250 are invoked.
A Control Adjacency Establishment (CAE) procedure 260 establishes a control adjacency between the control element(s) 201a, 201b associated with the ports presented via the “remote port detected” 126 notification. Towards this end, the CAE 260 procedure executing in control element 201a executes an “adjacency request” 316—“adjacency response” 314 transaction from CAE procedure 260 executing in management element 301. In one embodiment of the present invention, the information obtained by the “adjacency request” 316—“adjacency response” 314 transaction includes communication addresses (e.g., Internet Protocol addresses) of the specified control elements 201a, 201b associated with the ports presented via the “remote port detected” 126 notification. The combination of these addresses composes the context of the control adjacency between control elements 201a, 201b needed to carry out the subsequent link correlation procedures 350.
With the control adjacency successfully established by CAE procedures 260, Control Channel Establishment (CCE) procedures 270 executing on control elements 201a, 201b utilize a “control channel request” 324—“control channel response” 334 transaction to establish a control channel 210 within the context of the newly established control adjacency between control elements 201a, 201b.
In another embodiment of the present invention shown in
It may be desirable however, to establish a control channel 210 needed in support of signaling inherent to subsequent functions (i.e., routing, connection control, etc.) performed within the control plane 200.
As shown in
In an electrical signaling network, one type of physical transport standard used to communicate between network elements is Digital Signal 1 (DS1). DS1 (also known as T1) is a North American standard developed by an American National Standards Institute (ANSI) T1 subcommittee. A network link using DS1 has a total bandwidth of approximately 1.544 Mbps and is capable of multiplexing 24 potential channels for voice or data. Another type of physical transport standard is Digital Signal 3 (DS3), which provides a network link with a total bandwidth of approximately 44.7 Mbps and is capable of multiplexing 672 potential channels. In a DS1 network, the initiation message can be placed in a 16 byte portion of a packet overhead. Once a management element 301 processes the initiation message and makes a connectivity determination, management commands can then be sent over payload of the DS1 or be shared with user data. Similar techniques may be employed in an optical network, such as one using a Synchronous Optical Network (SONET) standard.
Those of ordinary skill in the art should recognize that methods involved in the present invention may be embodied in a computer program product that includes a computer usable medium. For example, such a computer usable medium can include a readable memory device, such as a solid state memory device, a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having stored computer-readable program code segments. The computer readable medium can also include a communications or transmission medium, such as a bus or a communications link, either optical, wired, or wireless, carrying program code segments as digital or analog data signals.
While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.
