Electrical computers and digital processing systems: multicomput – Computer-to-computer data addressing
Reexamination Certificate
2000-07-06
2004-05-18
Harrell, Robert B. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data addressing
C709S227000, C709S228000, C709S238000, C709S239000, C709S204000, C709S205000, C370S354000, C370S351000, C370S352000, C370S353000, C370S475000
Reexamination Certificate
active
06738828
ABSTRACT:
FIELD OF THE INVENTION
The invention relates to name resolution protocols, systems and methods for resolving a flat name space, such as the TL1 (Transaction Language 1) name space, to an address space, such as the IP (Internet Protocol) address space.
BACKGROUND OF THE INVENTION
FIG. 1
is a block diagram of a typical system containing a SONET (synchronous optical network) ring configuration. The system consists of a SONET ring composed of a plurality (three shown) of SONET network elements
10
,
12
,
14
, including a gateway SONET network element
10
in a central office
16
, and two end office SONET network elements
12
,
14
in two end offices
18
,
20
, the SONET network elements all being connected by a bi-directional fiber ring
20
. Each end office SONET network element
12
,
14
is connected to a respective subscriber line multiplexing switch/device
24
,
26
, which in turn is connected to subscriber devices (not shown) through respective groups of subscriber lines
28
,
30
. Each SONET network element
10
,
12
,
14
performs add/drop multiplexing of SONET frames.
The network element
10
in the central office
16
is shown connected through a DCN (data communications network) cloud
32
to a NOC (network operations centre)
34
running an OS (operations system)
36
. Operations staff work in the NOC
34
to perform OAM & P (operations, administration, maintenance and provisioning operations) functions through the operations system
36
. The DCN cloud
32
may be any connection of routers/switchers/bridges and/or LAN/WAN links. The communications from the SONET network through the DCN
32
to the NOC
34
are all control communications, not regular traffic, such as voice traffic.
It has become somewhat the defacto standard that operations systems such as OS
36
use TL1 (Transaction Language 1—defined in BellCore Telecordia GR-831-CORE) to communicate with the networks they are being used to manage.
In accordance with TL1, each network element
10
,
12
,
14
is aware of its own respective unique SID (system identifier). In TL1, the identification of a network element's SID is specified by a TID (target identifier) in a TL1 command from the OS
36
or in a response from a network element. It is the responsibility of the gateway network element
10
to route TL1 messages from the OS
36
to the appropriate network element based on the TID in each message. The gateway network element
10
communicates with the other network elements
12
,
14
using an embedded data communication channel, and thus a conversion from TL1 TIDs to the addresses of the embedded data communications channel must be made. Traditional SONET networks have used the OSI (Open Systems Interconnection) protocol suite over this embedded data communications channel, and this TID conversion function was done using TARP, another protocol specified in BellCore Telecordia GR-253-CORE.
Recently, efforts have been made to move away from the OSI protocol suite to use IP as the protocol over the embedded data communications channel. In such networks, the operations systems
36
would still be communicating in TL1, and thus the gateway network element
10
needs to perform address resolution from the TL1 name space to the IP space. The above identified TARP algorithm is an address resolution protocol originally designed to work in OSI networks, not IP networks. In theory, TARP could be adapted to work in an IP network. However, TARP relies on an inefficient packet flooding algorithm.
The Internet name space is hierarchical, with authoritative name servers translating names to IP addresses within that space. Domains can also be further subdivided into subdomains with authoritative servers for those subdomains. A lookup would start with the highest authoritative server (called root), walking through the hierarchy stopping at each authoritative server for each subdomain until the name has been resolved. The Domain Name System (DNS) has traditionally provided the name to IP address lookup functionality. DNS does not work for the TL1 name space because the TL1 name space is flat rather than hierarchical. The DNS root could be configured to understand all TL1 SIDs (system identifiers), but that would not work if the network elements are connected to the Internet because DNS would resolve all addresses to the well known DNS root server and that is where it would stop.
DNS was originally designed to work with static configuration tables which rarely changed. In a SONET network, network elements can be added, removed or may be isolated by fiber failure. While dynamic DNS (IETF RFC 2131) could be used to deal with this issue strictly in the IP domain, dynamic DNS does not solve the problem discussed above wherein SONET network elements are connected to the Internet.
LDAP (Light Weight Directory Access Protocol) is a distributed database that could also be used to solve the problem. This solution does not suffer from the DNS limitations, however it requires extra provisioning in the database records and a LDAP server each time a new network element is added.
Thus, to facilitate the implementation of IP-based SONET networks, it would be advantageous to have an efficient TL1 name to IP address resolution protocol.
SUMMARY OF THE INVENTION
Various embodiments of the invention provide network elements adapted to participate in an inventive name resolution protocol which performs name resolution from a flat name space, such as the TL1 name space, to an address space, such as the IP address space. Advantageously, a very efficient approach is used to resolving the flat name to the addresses which does not require any inefficient packet flooding, and which is adaptive to changes in a network which might occur.
One embodiment provides a network element adapted to implement the functionality by which a name resolution can be requested, i.e. the requesting functionality of the protocol. Such a network element has a first memory element adapted to store one or more local name of the network element, the local name belonging to one or more flat name spaces, and a processing element adapted to process a requested name by determining if the requested name is one of the local names, and if not to send a request message to a group of network addresses in the address space belonging to network elements which have joined the group, the request message containing the requested name for which a corresponding address is required.
The network element may further comprise a second memory element adapted to store previously resolved name-to-address mappings. In such a case, the processing element is adapted to process the requested name by determining if the requested name is one of the local names or a name of a previously resolved name-to-address mapping, and if not to send the request message.
The network element is typically further adapted to process a response messages specifying a particular network address for the requested name, and to add a name-to-address mapping to the second memory element identifying the particular network address as being the network address for the requested name.
The group of addresses might for example be a multicast group of IP addresses. The network element typically is equipped with an interface for receiving a command from an external source such as an operations system, the command specifying the requested name.
Another embodiment provides a network element adapted to perform the reporting functionality, i.e. to respond to requests generated as outlined above. Such a network element has a stack with a local address, and a memory element adapted to store one or more local names of the network element. The network element also has a procedure by which the network element joins a group of addresses, and request message processing functionality adapted to process a request message containing a requested name for which a corresponding address is required by comparing the requested name with the local names, and if there is a match with any one of these, to reply with a response message specifying the local a
Barry Peter J.
Corkum Trevor D.
Keats Bruce D.
Harrell Robert B.
Nortel Networks Limited
LandOfFree
Name resolution protocol, system and method for resolving a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Name resolution protocol, system and method for resolving a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Name resolution protocol, system and method for resolving a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3193186