Name resolution protocol, system and method for resolving a flat name space to an address space

[0002] 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.

[0003] 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.

[0004] 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.

[0005] 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.

[0006] 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.

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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.

[0014] 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.

[0015] 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.

[0016] 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.

[0017] 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 address.

[0018] Network elements might be equipped with either or both of the requesting and reporting functionality. The network elements might for example form part of a network in which network elements are connected in an add/drop configuration so as to perform an add/drop multiplexing function on physical layer frames being transmitted on the network.

[0019] In embodiments employing the IP hierarchical address space, the network elements have a stack interface between IP packets and physical layer frames which might for example be SONET frames. The stack interface might for example be adapted to insert the IP packets in a channel defined by predetermined byte locations in the physical layer frames. In the event the physical layer frames are SONET frames, such predetermined byte locations might for example be SONET D1 to D12 overhead bytes.

[0020] Another embodiment provides a network of network elements each as summarized above, for example a SONET ring of network elements.

[0021] Advantageously, the solution does not require an additional provisioning on the network elements, and maintenance is not required when a network element is added to the system.

[0022] Further embodiments of the invention also include methods of realizing any of the above functionality, and include computer readable medium containing computer instructions which implement these instructions.

[0023] Preferred embodiments of the invention will now be described with reference to the attached drawings in which:

[0024] FIG. 1 is a block diagram of a typical system containing a SONET ring configuration;

[0025] FIG. 2A is a functional diagram of a network element adapted to implement a TL1 to IP address resolution protocol in accordance with an embodiment of the invention;

[0026] FIG. 2B is an example of stack configurations which might be used with the network element of FIG. 2A;

[0027] FIG. 2C is a block diagram of the network element of FIG. 2A;

[0028] FIG. 3 is a flowchart of the steps performed by a gateway network element in requesting an IP address matching a TID in accordance with an embodiment of the invention;

[0029] FIG. 4 is a flowchart of steps executed by a network element in responding to a request for an IP address matching a TID;

[0030] FIG. 5A contains details of an example protocol format;

[0031] FIG. 5B is an example request message using the protocol format of FIG. 5A;

[0032] FIG. 5C is an example response message using the protocol format of FIG. 5A; and

[0033] FIG. 6 is a summary of the message exchange used to perform the TL1 to IP address resolution protocol in accordance with an embodiment of the invention.

[0034] An embodiment of the invention will now be described in the context of a SONET ring of network elements each having an IP address and in the context of TL1 message commands containing TL1 addresses which need to be resolved to IP addresses.

[0035] A functional diagram of a network element adapted to implement an embodiment of the invention is shown in FIG. 2A. Shown are three components, namely a TL1 application 40, a TIP (TL1 to IP) engine 42, and a SID (system identifier) manager 44. The TL1 application 40 is an application on the network element which processes TL1 commands in the event they are addressed to the particular network element, and which forwards the message on to the appropriate network element in the event they are not addressed to the particular network element. The SID manager 44 is simply responsible for maintaining knowledge of the SID for that network element. It is noted that a given network element may have more than one SID (more generally a given network element might have multiple flat names belonging to one or more flat name spaces), and the SID manager 44 would be responsible for maintaining knowledge of each flat name. The TL1 application 40 interfaces with the TIP engine 42 which in turn interfaces with the SID manager 44 to determine the particular network element's SID. The TL1 application 40 makes a request to the TIP engine 42 when it needs to resolve a TID to an IP address. The TIP engine 42 processes such a request in a manner described in detail below with reference to the flow chart of FIG. 3.

[0036] When a network element is activated, its initialization procedure initializes and starts the TIP engine 42. The TIP engine 42 defines a multicast group which ultimately includes addresses of all the network elements in the network of which the network element is a part. A multicast group is a class D IP address. Any IP packet addressed to the multicast address is sent to all of the IP routers and hosts that are members of the group. Alternatively, the TIP engine 42 causes the network element to join this multicast group if it is already in existence. More generally, every network element is configured to join the multicast group, for example during initialization, or to create the multicast group if the particular network is the first activated. More generally still, the network elements are included in a group of network addresses. For the purpose of this explanation, this multicast group will be a multicast group having a predetermined name, for example “AllSC” (all shelf controllers) since OAM & P functions are part of the shelf controllers. Each network element is configured to join the AllSC multicast group upon startup. The network elements might join the AllSC multicast group using the IGMP protocol for example. The IGMP is the Internet Group Message Protocol defined in IETF RFC 1112 and IETF RFC 2236.

[0037] Each network element has its own SID (maintained for example in a memory element under control of the SID manager) and also maintains a database, table or other suitable structure in another memory element, such as a cache, which maps TIDs to IP addresses for IP connections from the particular network element to another network element in the network, as described in detail below. More generally, there is a mapping of flat names in a flat name space to respective addresses in an address space. For example, a table such as shown in Table 1 below has a first column containing TIDs, and a second column identifying corresponding IP addresses. As TIDs are resolved to IP addresses, this table is expanded to include additional records. The database might for example be a cache of fixed size. This keeps the amount of memory needed small. Entries may be removed when time expires or when no more space exists in the tableland a new entry must be added.

[0038] As described below, the TID to IP address mappings are used to reduce the amount of required messaging. If this reduction in messaging is not a priority, the invention could be implemented without maintaining these mappings and by instead sending the multicast message every time the TID does not match the local SID.

[0039] FIG. 2B illustrates details of the stack interfaces implemented in each network element. An IP stack 100 is shown together with native interface protocols ICMP (Internet Control Message Protocol defined in IETF RFC 792) 102, TCP (Transmission Control Protocol defined in IETF RFC 793) 104, IGMP (Internet Group Message Protocol defined in IETF RFC 1112 and RFC 2236) 106 and UDP (User Datagram Protocol as defined in IETF RFC 768) 108 all running in a layer over IP (Internet Protocol defined in IETF RFC 791) 100. Also shown for completeness are ARP (address resolution protocol defined in IETF RFC 826) 110 and RARP (reverse address resolution protocol defined in IETF RFC 903) 112. Dotted line 114 represents the user application/IP stack interface. As described previously, the TIP engine 42 represents the functionality provided by an embodiment of the invention and this may be run as a user application above the IP layer 100 and interfaces with the stack through the application interface 114. Dotted line 116 represents the IP stack interface to the physical devices which carry traffic between network elements. For a SONET-like network for example, this might include an interface into SONET overhead bytes D1 to D12 in which case bytes are taken form the IP layer and inserted into the bytes D1 to D12. The large arrows are intended to show data flow in the stack.

[0040] An example internal architecture of a network element is shown in FIG. 2C. Each network element has a shelf controller 50 which is responsible for control functionality in the network element, and has a plurality of port cards 54,55 (three shown). There is a switching element 52 which performs switching of SONET frames between the various port cards 54,55. In the event the network element is a gateway network element, the gateway network element's SC 50 has an external interface 57 to the previously identified connection through the DCN cloud 32 to the NOC 34 (see FIG. 1). The shelf controller 50 has processing and memory capability, for example processor 70, and RAM/flash memory 72, and has a control interface 74 to each ofthe port cards 54,55 and to a control interface 53 forming part of the switching element 52. One of the port cards 55 is for connection to the external subscriber line multiplexing switch/device (for example device 24 of FIG. 1) to which subscriber lines may be connected. The switching element 52 consists of any mechanism for switching SONET frames between port cards 54,55. The switching element 52 interfaces with each port card 54,55 through a respective SONET framer 58 which in turn produces an output in the format required by the port, this being SONET frames for port cards 54 which are each connected to a respective laser 60 to the fiber ring. Some other format may be required by the external switch/device, and port card 55 would perform this conversion. Similarly, SONET frames received from the fiber ring may be passed to switching element 52 and on to the appropriate subscriber device through the subscriber lines. Port cards may also be provided for interfacing to other networks.

[0041] The IP stack defined above with respect to FIG. 2C would typically be implemented in the processor 70 in the shelf controller 50. Similarly, the processor 79 would typically implement the TIP engine, TL1 application and SID manager of FIG. 2A. These applications may be combined as a single application or partitioned into separate applications. They may be implemented in software, processor hardware such as an ASIC, FPGA, and/or/be delivered in a computer readable medium such as a disk, tape etc. IP packets would go through control interfaces 74,56 to be delivered to/from the appropriate port cards where they are inserted into/read from SONET overhead bytes D1 to D12 by the appropriate SONET framer 58.

[0042] The TL1 name to IP address resolution protocol provided by this embodiment of the invention can be divided into request functionality which is implemented by a network element receiving the TL1 message for distribution (usually a gateway network element), and report functionality implemented by each network element in response to requests from the request functionality. Typically, each network element is equipped with a TIP engine providing both the request and report functionality. However, for network elements which have no interface for receiving or generating TL1 commands, the request functionality becomes optional, and the TIP engine might only include report functionality.

[0043] A method of performing a TL1 to IP address resolution request functionality provided by an embodiment of the invention will be described with reference to the flowchart of FIG. 3. This method might be implemented by the gateway network element 10 of FIG. 1 for example.

[0044] The method is initiated upon receipt at the gateway network element 10 of a TL1 command (step 3-A). Each TL1 command contains a TID. More specifically each TL1 command has the following format {<command>:TID:AID:CTAG:<parameters>} where <command> specifies a particular command for the message, TID is the target identifier, AID is the access identifier identifying a facility on the target, and CTAG is a correlation tag to allow messages and responses to be matched up. There may be additional parameters. The TL1 application 40 examines the TID (step 3-B), and if the TL1 command contains the TID which matches the SID of the gateway network element (the local NE) as specified by the SID manager 44 then the message is processed by the gateway network element (step 3-C). The details of actual processing of the messages by the network elements to which they are addressed is outside the scope of this invention. Otherwise, the TIP engine 42 is asked to determine the IP address which matches the TID. In the event the TID does not match the SID of the gateway network element, the TIP engine looks up in its cache (for example in the format of Table 1 above) to determine whether there is an existing record for the TID or not (step 3-D). In the event the TID is in the cache, the address has been previously resolved and the message is sent to the IP address for that TID (step 3-E). In the event it is determined that the TID is not in the cache, a TID request message is constructed.

[0045] An example format of the TIP messages is shown in FIG. 5A. As indicated above, there are two basic functions supported by this protocol. The first is the request functionality which requests the IP address for a given TID (or simply request), and the second is to report the IP address of a given TID. (or simply report). The protocol uses a port which might be predetermined and/or configurable. For example, the UDP port might be pre-configured to UDP port number 20862. A TIP message is built as a PDU (protocol data unit) and is sent in network byte order in the dataportion of an IP packet. In this embodiment the IP packets are sent in SONET overhead bytes D1 to D12. The message optionally includes a version number 50 which is a version of the address resolution protocol. There is a command field 52 which identifies the message as a request or a report. For example, “1” might indicate “request”, and “2” might indicate “report”. There is optionally one or more sanity fields, for example a “magic cookie” field 54. There may be a “time to live field” 56 (representing a period in seconds that the data is valid) and a sequence number field 58 (incremented each time a new request is sent). There is an originator's TID length field OrigTIDLen 60 identifying the number of bytes in the originator's TID field that are valid, and this field is followed by the originator's TID 62. The TID length field 60 might be for example from 0 to 20. There is a field for the originator's address length OrigAddrLen 64 again indicating the number of bytes of the originator's address which are significant. This is followed by an originator's address type field 66. The type of address might for example be interpreted in accordance with the ETHER TYPES defined in RFC 1700. In the event IPv6 address type is used, the type is defined in RFC 2464 as 86DD hex. There is a field 68 for the originator's address which is used to store the IP address of the originator (the gateway network element's IP address). This is the IP address where the response to this message is to be sent. The requested TID length ReqTIDLen 70 is the maximum number of bytes that are significant in the requested TID field 72. This might for example be constrained to the range 1 to 20. The requested TID field 72 is for storing the TID of the entity being searched for. The requested address length ReqAddrLen 74 is the number of bytes in the requested address field which are significant. The requested address type 76 is the type of the address. The Requested IP address field 78 is for containing the IP address matching the requested TID.

[0046] An example request message is shown in FIG. 5B.

[0047] Returning now to FIG. 3 and with reference to FIGS. 2A and 2B, a TID request message is constructed (step 3-F), the version 50, Command 52 (=request), magic cookie 54, originator's TID length 60, originator's TID 62, originator's address length 64 and type 66, originator's IP address 68, Requested TID length 70 and Requested TID fields 72 are all filled in. This message is then handed off to the application interface 114 which in turn hands it to UDP 108 which adds a UDP header and sends it on to the IP layer 100. The IP layer 100 then adds its header, setting in the destination IP address as the AllSC multicast address and hands the packet off to the device drivers through the stack device interface 116. The device drivers then send the packet off out over the physical interfaces. The result is that the packet is sent around to all the network elements in the network using IP multicast (step 3-G). Every network element that is a member of the multicast group receives the request. IP multicast attempts to deliver packets but does not guarantee delivery. The request might be retransmitted a number of times in the event a response message is not received, for example three times with a reconfigurable delay between retransmissions, for example 30 seconds. The IP time to live value 56 will determine when the PDU will die. In response, one of the network elements will respond with an IP unicast message to the originator's IP address by returning the request message with the requested IP address filled in. Details of how the network elements process the multicast message are provided below with reference to FIG. 4. Upon receipt of the response (step 3-H), the unicast message is sent up the stack and finally delivered to the TIP engine 42 and finally the TL1 application 40. The TIP engine 42 updates its cache to include the newly resolved TL1 address—IP address pair. The gateway network element can then send the TL1 command on to the IP address thus identified (step 3-I).

[0048] An example of a TID response message is shown in FIG. 5C corresponding with the request message of FIG. 5B. The report functionality which processes the above-introduced multicast messages in the network elements of the multicast group will now be described with reference to FIG. 4. Upon receipt of such a request message (step 4-A), the network element sends the packet up the stack, stripping the IP and UDP headers, and finally the packet arrives at the application interface 114. From the application interface the packet is sent to the TIP engine 42 which queries the SID manager 44 to see if there is a match between the requested TID and the network element's SID (more generally any one of the network element's SIDs). More specifically, (step 4-B) the TIP engine 42 looks at the version number 50, magic cookie 52, and TID 72 to determine if there is a match between all three of these fields and local values. In the event there is a match (Yes path, step 4-C), the network element generates a report command message (step 4-D). Most of the fields in the report command are copied from those fields in the received request command. The Requested IP address field 78 of the report address is filled in with the IP address of that network element. This packet is then sent through the stack which adds the UDP and IP headers with IP unicast to the originator's IP address thereby completing the processing of the message (step 4-E). In the event there is no match (No path, step 4-C), the message is discarded without further processing (step 4-F).

[0049] It is noted that a given network element may in some circumstances have more than one IP address. In such a network element, preferably only one of the IP addresses is selected upon configuration to be in the multicast group. In the event the network element also has multiple SIDs, it is possible to always respond to a request relating to any of the SIDs with a common IP address. Alternatively, it is possible to respond to a request relating to a particular one of the SIDs with a particular one of the multiple IP addresses.

[0050] It is noted that in most implementations, the network element itself contains the routing software, therefore the initial IGMP will be internal to the network element. Multicastextensions to OSPF (called MOSPF) is the preferred method for TIP. Since TIP is an application protocol, it does not matter which multicast approach is chosen. TIP will work with PIM Sparse, CBT, DVMRP, or PIM Dense, for example.

[0051] FIG. 6 summarizes the interaction between the above discussed request functionality and report functionality. To begin, all network elements including gateway network elements and regular end office network elements join the multicast group through an IGMP message 200. Next, after a TIP engine for example running on the gateway network element, receives a request, it generates a TID request message 202 and sends this to all network elements through IP multicast. Each network element receiving the TIP request examines the TID and determines if it matches the locally stored SID. If there is a match, a TID response message 204 is generated and sent by IP unicast back to the engine which originated the request.

[0052] Numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practised otherwise than as specifically described herein.

[0053] For example, while an embodiment of the invention has used the TL1 address space, more generally any name space may be used. While the invention has used the IP address space, more generally any address space may be used.

[0054] Where an example has been described in the context of SONET network elements, for the purpose of this description a network element is any component having a flat name which needs to be resolved, for example routers, hosts, switches etc.