In communications networks including multiple nodes, it may be desirable to ensure a link connecting two nodes is capable of carrying a desired amount of traffic. This process is referred to as “link proving” and may be performed before a link is brought into service by exchanging link proving messages between two nodes for the purpose of link proving. For example, in a Signaling System No. 7 (SS7) network, link proving may be performed by transmitting and receiving status indication normal/emergency signaling unit (SIN/SIE) messages between two SS7 nodes.
During an SS7 link proving period, SINs are continuously transmitted over the link in both directions (SIEs are used when a shorter proving period is desired). SINs are transmitted at the full bandwidth of the SS7 link being proven for a predetermined link proving period. For example, Bellcore standard (GR-246-CORE) specifies a proving period of 2.3 seconds for a 56 kb/s DS0 link. A determination of the capabilities of an SS7 link may be made by examining information contained in these SINs. For example, SINs carry Level 2 information, such as a cyclic redundancy check (CRC) checksum for verifying the integrity of received messages. A CRC checksum is included in SINs because Level 2 SS7 signaling nodes do not perform hardware layer data integrity verification upon receipt of an SIN. Therefore, corrupt or incomplete SINs may be received at layer 2 based on specifications laid out, for example, in Bellcore standard GR-246-CORE.
However, as network operators increasingly move to Internet protocol based networks which must interoperate with conventional SS7 standards, translating SS7 link proving constructs to the IP domain has been problematic. One problem associated with performing link proving for IP links is that IP protocols, such as M3UA and SUA, are effectively shielded from receiving and detecting missing, corrupt, or incomplete packets necessary for performing link proving, because the underlying network and transport protocols correct data integrity error, and the transport protocol requests retransmission of lost packets.
The Internet engineering task force (IETF), via the signaling transport (SIGTRAN) working group, has specified several protocol standards for communicating SS7 signaling messages over an IP network, including message transfer part 3 user adaptation (M3UA), message transfer part 2 user peer-to-peer adaptation (M2PA), and signaling connection control part user application (SUA). SUA, M3UA, and M2PA are adaptation layer protocols which sit on top of stream control transmission protocol (SCTP) and IP, which each perform data integrity checks on packets (chunks in SCTP parlance) before passing them up to the M3UA or SUA layer. SCTP is a reliable connection-oriented transport protocol operating over IP. SCTP resides in the transport layer and handles communication among programs in a network. This includes accepting data from the application layer and repackaging it so that it may be passed on to the network layer. In addition, the transport layer will ensure the data arrives correctly on the other end using sequence numbers and retransmission timeouts.
For example, upon receiving an M3UA chunk, hardware implementing the IP protocol may examine each packet using a checksum included in the packet for corrupt or incomplete packets. This IP layer may then discard the bad packets which is detected at the SCTP layer by checking for gaps in the sequence numbers of arriving packets. A similar data integrity checked is performed at the SCTP layer. The SCTP layer passes the corrected packets or chunks to the adaptation layer. As a result, packets received by the M3UA layer contain no errors. Because the adaptation layer carries the SS7 message traffic and that traffic is corrected, conventional link proving that relies on detecting errors in received FISUs cannot be performed.
Additionally, conventional IP link proving methods typically include exchanging a limited number of messages in a short period of time in order to bring the link into service as quickly as possible. For example, Heartbeat messages may be sent and corresponding Heartbeat Acknowledgement messages may be received in order to measure a round trip time (RTT) for the link. If the measured RTT is within acceptable limits, the link may be proved and immediately brought into service.
One problem associated with conventional methods for IP link proving, including IP link proving, is that unstable or poorly performing links may be brought into service. For example, link performance may be satisfactory for low message volumes and small message sizes, but may be unsatisfactory for higher message volumes and larger message sizes. Because typical message volume for live traffic traversing an IP link greatly exceeds the number of messages used for conventional link proving, conventional link proving methods may inadequately indicate link performance.
For example, an IP link may be rated at 1.5 Mb/s (i.e. expected to carry 1.5 Mb/s message volume). However, for various reasons, the link may only be capable of operating at 1 Mb/s. During conventional link proving, only a fraction of the link capacity is used, and therefore the link may be proved and brought into service. For purposes of illustration, assume that conventional link proving methods utilize 0.1 Mb/s of the 1.5 Mb/s link (operating suboptimally at 1 Mb/s) as described above. Upon proving the link it is brought into service, and live traffic may be placed on the link at its expected capacity of 1.5 Mb/s. However, because the link is operating suboptimally, the link may become congested and/or fail. Packets may then be routed around the failed link and a restart procedure may begin. During the restart, conventional link proving may again be performed at low message volumes and low transmission rates. Accordingly, the link may be proved again. However, because the message volume associated with conventional link proving may not adequately assess link performance at live traffic volumes, an accurate assessment of link performance may not be achieved. Therefore again, the link may fail when message volume exceeds the links ability to handle it and an undesirable process of cycling the link between active and inactive status is repeated.
Another problem associated with conventional methods for performing IP link proving is that conventional IP link proving does not individually prove paths within a multi-homed SCTP association. For example, a primary path in a multi-homed SCTP association may be capable of operating at a first capacity and a second path in the SCTP association may be capable of operating at a second capacity, where the first capacity is different from the second capacity. Conventional methods for link proving may only exchange link proving messages over the first path in the link, leaving the performance of the second association either unproven or inadequately proven.
Another problem associated with conventional methods for performing IP link proving is that no monitoring of link performance is performed after a link has been proved and brought into service. For example, in a conventional network, a link may be proved at its final rated capacity and then, subsequently, its performance may deteriorate. This deterioration may go undetected by system operators until a link failure occurs in a conventional network because no performance monitoring is performance after the link is brought into service.
Accordingly, there exists a need for improved methods, systems, and computer program products for performing IP link proving using heartbeat messages.