1. Field of the Invention
The present invention relates generally to address protocols for transmitting information packets between the nodes of a network and to methods of network fault detection and isolation.
2. Description of Background Art
Packet data networks, such as optical networks and computer networks, have network nodes coupled by data links. There are a variety of different network topologies, such as linear, branched, mesh, and ring topologies. Packet data networks transmit data to network nodes in the form of message packets. Each message packet comprises a protocol data unit (PDU) that includes a message body (also known as the payload) and a header. The header contains source and destination address information that other network elements use to forward the message packet to its intended destination.
Conventional packet message forwarding techniques rely upon each node of a data network having a pre-determined network address. The address of each node may be assigned at the time the network is designed or may be assigned via a configuration process, such as a broadcast configuration process in which the nodes negotiate specific node addresses. In either case, prior to using the network for data communications, each network node has a pre-determined address. Network elements forward the message packet through the network to the receiving node based upon the pre-determined address along with other information related to protocols or rules for forwarding a message packet for a particular network topology.
There are several commonly used address protocols used in the network industry. These include the Ethernet address protocol, described in the Institute of Electrical and the Electronic Engineers (IEEE) standard 802.3, and Internet Protocol (IP) address standard, described in the request for comment (RFC) 791.
FIG. 1A is a prior art illustration of representative IP address datagram header 100 described in RFC 791. The IP datagram header is the “envelope” in which data is transmitted. It includes header data fields for the Internet Protocol source address 105 of the host sending the datagram and the Internet Protocol destination address 110 of the host to receive the message packet. It also includes other standard data fields, such as a version field 115 which is the version number of the protocol; an Internet header length (IHL) field 120 corresponding to the length of the header; type of service field 125 corresponding to various levels of speed and reliability; a total length field 130 corresponding to the total length of the datagram; an identification field 135 which is a value used for a fragmented datagram to indicate that a fragment belongs to a particular datagram; a flags field 140, typically used to indicate whether the packet is the last fragment; a fragment offset field 145, used to indicate where the datagram fragment belongs in a set of fragments; a time to live field 150, which is decremented with every pass through a router and which is used to discard a packet after a preset number of routing attempts; a protocol field 155 corresponding to the transport layer process used to accept the datagram; a header checksum field 160, which is an error correction code for the header; and options/padding field 165, an optional information and filler added so that the header is a multiple of 32 bits. FIG. 1B is an exemplary portion of a message packet in accord with the RFC 791 standard. As can be seen in FIG. 1B, the header data fields of a particular packet correspond to numerical codes. Additionally, message packet 100 includes other user data fields 160, 165, 170 for performing other functions, such as transporting a payload.
FIG. 2A is a prior art illustration of a representative Ethernet address header 200 similar to that described in IEEE standard 802.3. It includes fields for the source address 205 and destination address 210 of the message packet. FIG. 2A also shows a continuation destination address field 220 and a continuation source field 225 for 48 bit address fields, in accord with a conventional visual representation of an Ethernet address header 200. Additionally, it includes a data field for the Ethertype 215. The Ethertype field is a code that is assigned by the IEEE Ethertype Field Registration Authority. The Ethertype field is typically used to provide a means of protocol identification, i.e., the developer of a data transport protocol registers an Ethertype. There is one Ethertype reserved for IP packets over Ethernet. Additionally, as shown in FIG. 2B, an organization may obtain an Organizationally Unique Identifier (OUI) from the IEEE Registration Authority to uniquely identify each node of a network. Each IEEE network interface is uniquely identified. An Organization building nodes may obtain an OUI from the IEEE from which they can create unique identifiers, i.e., the organization may buy a range if potential IDs that can be distinguished by the OUI field and then assign these IDs to the equipment they provide or sell. The OUI/company ID is a 24 bit globally unique assigned number. The OUI is used in the family of IEEE 802 standards for local area networks, Ethernet, and token rings. The OUI is used by a manufacturer to specify the unique media access control (MAC) address for each device produced by a manufacturer. For example, an OUI can be used to generate 48-bit Universal local area network MAC addresses to uniquely identify LAN stations and metropolitan area network (MAN) stations. A single Ethertype field is all that is required to limit reception of a message packet to a particular class of devices. There are also provisions for sub-type fields. FIG. 2B shows an exemplary destination address field for an IEEE 802 MAC header. It includes an OUI field 270, a vendor field 275, and other optional fields 280, 285. The M-bit 280 in the Ethernet address can be used to establish a multicast address to be received by a group of stations. There is also a broadcast address option to permit all Ethernet interfaces to receive a frame having the broadcast address.
Data networks may experience failures in individual nodes or the data links between nodes. FIG. 3 shows a linear chain network 300 having a plurality of network nodes 302, 304, 306, and 308 coupled by data links 310. Network 300 may, for example, comprise a chain of network elements regenerating a signal over a long distance. Network 300 may also comprise a portion of a larger network, such as a branched chain network (as indicated in phantom) with data links 380 and 382 and nodes 390 and 392 coupled to node 308. As illustrated by break 315, a fault may occur along a portion of a data link. Alternately, a signal node, such as node 304, may also fail and disrupt traffic.
Network faults disrupt communications between network elements, resulting in lost data traffic. It is desirable to quickly detect not only the occurrence of a fault but also its location so that redundant elements may be switched into service and/or field repairs made to repair the fault commenced as soon as possible. For optical networks, one approach to the problem of network faults is the synchronous optical network (SONET) protocols for monitoring performance in the time division multiplexing (TDM) domain. However, in the event of a network fault provisioning and configuration of the network elements is required with new addressing and routing information, i.e., the system negotiates and assigns new fixed addresses for each node after determining the topology of the system and the new signal paths.
One drawback of conventional message packet protocols is that it may take longer than desired for the network to perform the provisioning and configuration process to determine the new topology and/or assign new addresses. This may result, for example, in lost traffic during the provisioning and configuration process. The time required to negotiate and assign new addresses also limits the ability of the system to make electrical equipment switches or line equipment switches on sub-sections of the network.
Therefore, there is a need for an improved message packet protocol for data networks that can deliver message packets even if the network is not provisioned or configured.
USPTO Backgrounds
USPTO Backgrounds