the invention basically comprises four major operations . the first is the call set - up , the second is data transmission , the third is path update , and the fourth is the recovery plan . as shown in fig1 the inventive ip packet has an extra or modified header such that it has a static field and a dynamic field . the static ( control ) field 16 , is used to establish connection / ack connection / data transmission ( typically 2 - bit , but not limited thereto ), where ‘ 01 ’ means establish connection , ‘ 10 ’ means ack connection , and ‘ 11 ’ means data transmission . the dynamic fields are typically pairs of two bytes in the header that contain the index port numbers for the source and the destination ni ( network interface ) addresses ( next hop ) one byte for each direction . in other words , each pair of these two bytes represents the information of the outgoing ports ( ni addresses ) for next hop ( a router ) for both directions . the more hops from a source to a destination , the more information , such as pairs of the two bytes are added to the header . this addition is only performed in a call set up stage with maximum of 255 hops . this maximum number can be changed if needed . in a data transmission stage , only one column in fig1 plus the control field 16 , are used according to the direction of the ip packet . also , each router , in an ip packet &# 39 ; s path , should have its local router interface table , which is stored locally . as shown in fig2 the table has two fields , the index field 22 , and the ni address field 24 . thus , all the interfaces in a particular router will be listed in this local router interface table . this index &# 39 ; s value will be stored in one byte of the pairs of the two bytes in the header as shown in fig1 . this is to avoid storing the ni address ( for example mac address is 48 - bit ) in the header . having all this information in a roacm header ( in an ip packet ) and the local router interface table at each router , a router will immediately check the relevant fields in both the roacm header and the local router interface table and shunt the ip packet to the next hop . thus , all ip packets going to the destination , routers do not need to check the ip address for each packet any more , but just pick up the index port number field located in the roacm header , which is attached to all ip packets and immediately get the ni address corresponding to that index at the local router interface table and use the ni address to cross - connect all ip packets . moreover , packet reordering in the internet can be eliminated . this can be achieved by using the index in the header to associate it with a complete path through the router also identified as a packet handling device . this way packet reordering inside the router or packet handling device can be eliminated , thereby increasing the speed and reducing the delay in the network . therefore , routers or packet handling devices , using this protocol , can cope with the enormously increased traffic . at the set - up stage , the source workstation sets the establish connection / ack connection / data transmission control field with value ‘ 01 ’, which means establishing the connection . therefore , a first regular ip packet will be sent to establish the connection and collect the information . when the ip packet reaches an edge router , this router or packet handling device searches for the destination ip address in the forwarding ( or routing ) table . the main aim of this search is to find the corresponding ni address for the next hop ( router ). once it finds it , the router will use this information to forward the ip packet . a router should have a local router interface table that contains an indexed list that each index corresponds to an interface ( ni address ) connected to the router ( this list is stored locally in each router ) as shown in fig2 . therefore , the router or packet handling device adds this index port number in the header , as illustrated in fig1 , which corresponds to the ni address in the local router interface table ( for example , the index value ‘ 5 ’ instead of storing the ni address in the header , which in case of a mac address , the ni consists of 48 bits ) in the ip packet &# 39 ; s extra header , specifically , in the right side byte of the first pair since it is the first hop toward the destination . immediately after finishing the above process , the router gets the ni address for the opposite direction ( input interface ). this can be found in the destination physical address at the data link layer of the same packet , and stores the index port number in the ip packet &# 39 ; s extra header , specifically in the left side byte of the first pair since it is the first hop from the source , as illustrated in fig1 . thus , a pair of two bytes of information would belong to a particular router . this information is attached to the ip header in a call set - up while half - size of this information will be stored to the roacm header in ack connection and data transmission stages . the ip packet then moves to the next hop ( enterprise or core router ). at this router ( the second hop ), the router or packet handling device will repeat the same process again as the first router did . that is , the router finds the output ni address by searching the forwarding ( or routing ) table , and finds the input ni address by getting it directly from the same incoming packet and gets their corresponding index port numbers from the local router interface table . after that , it will add these index port numbers in the ip packet &# 39 ; s extra or modified header in the second pair of the two bytes . finally , the router or packet handling device forwards the ip packet to the outgoing interface . this process will continue until the ip packet reaches the destination or edge router . therefore , each pair of the two bytes represents the indexes of the corresponding network interfaces for a particular router in the ip packet path . one of these bytes is for the forward direction while the other is for the backward direction . in other words , the right side column 14 as shown in fig1 is in the forwarding direction while the left side column 12 , is for the backward direction . all information in fig1 is stored in the source and the destination workstations . when the ip packet goes in the forward direction , only the forward information and the control field are attached , as shown in fig3 , and when the ip packet goes in a backward direction , only the backward information and the control field are attached . hence , half - size of the information is carried in the roacm header . thus , in the data transmission stage , the router will immediately look at this information to get the index numbers and find the corresponding ni addresses stored locally in each router in the ip packet path to move to a next hop . so , it forwards the ip packet without looking up in the cache ( or routing ) table . the source and the destination workstations are responsible to add the right information ( forward / backward header ) in the roacm header ( the information could be added at the edge routers ), since the workstations ( source and destination ) keep a copy of the information , as illustrated in fig1 , where the roacm header encapsulation starts . also , the workstations ( source and destination ) keep a copy of their edge routers &# 39 ; mac addresses , so that it can send the ip packet immediately . by the time the first ip packet reaches the destination workstation , this ip packet has all information about the index port numbers as their ni addresses are stored locally in each router ( hop ) in the ip packet &# 39 ; s path . this information is in the forward and the backward header . a copy of this information as stated earlier is kept in the destination workstation . the acknowledgment will be sent back to establish the connection ( as specified by tcp / ip protocol ), where a copy of the complete information is attached as a data to be stored in the source workstation . before sending the ip packet back , the destination workstation sets the establish connection / ack connection / data transmission control field with value ‘ 10 ’, which means the ip packet is coming back with the header information as a data . also , it uses only the backward header information in the roacm header . the destination workstation then sends back the ip packet to the source workstation that contains the complete header information and the connection ack . therefore , the ip packet will be cross - connecting from the destination workstation to the source workstation . once the ip packet reaches the source workstation with value of ‘ 10 ’ ( ack the connection ), it knows that the data of this ip packet is in fact the complete header information , and the connection is established . a copy of this information should be stored in the source workstation . the source workstation will attach a copy of only the forward roacm header information in each subsequent ip packet that it sends out to the destination with the control filed of value ‘ 11 ’, which means data transmission . for all subsequent ip packets going to the destination workstation , routers do not need to check the ip addresses anymore nor they are performing switching , but only look at the index port number field in the roacm header at each frame and immediately get the corresponding ni address , stored in the local router interface table and use it to cross - connect the ip packets . thus , there is no routing or switching , but only cross - connecting . after establishing the connection , data is transferred forth and back between the source and destination workstations . it is not necessary that this route continues to be the optimal path . in other words , if at time = t 0 , when establishing the connection , the optimal route is stored in the roacm header , but it is not necessary that the same is true at time = t 1 . thus , a periodic refresh message should be sent to update the preferable route . if any output port malfunctions , the router would preferably send a message to the source workstation to stop sending any more ip packets and should re - establish the connection . it is preferred that the header information is stored in the roacm header in a stack fashion , i . e ., last in first out ( lifo ). also , the control filed ( 2 - bit ) would be attached at the top of the stack . for the purposes of illustration as shown in fig4 if a connection is established with three routers ( hops ), then the packet will have 6 bytes of header information ( three for forward header information , right column 14 ( fig1 ), 54 ( fig5 ), with the values ‘ 4 ’, ‘ 6 ’, ‘ 8 ’, and the other three for the backward , left column 12 ( fig1 ), 52 ( fig5 ), with the values ‘ 1 ’, ‘ 3 ’, ‘ 5 ’) plus 2 - bit control field header 16 ( fig1 ), 56 ( fig5 ) with the value ‘ 10 ’, as illustrated in fig5 . the destination workstation or device 45 , sends back the ip packet , which contains the header information as data . it encapsulates only the backward information and the control field in the roacm header such that the first hop ( 1 - byte ) information , as shown in fig5 , is located at the last position in the stack and the last hop is at the top of the stack and after this there is the 2 - bit control filed , as shown in fig6 a . in the data link header ( dlh ), the source mac address ( belongs to the workstation ) and the destination mac address ( belongs to the ethernet router interface ) are stored in the workstation for fast transmission , since the workstation knows its ni and also can have a copy of the router ni . once the ip packet reaches router 44 , it extracts and checks the 2 - bit control field . if it has the value ‘ 10 ’ or ‘ 11 ’, it performs cross - connection . since it is an ack connection , the value must be ‘ 10 ’. then , router 44 , extracts the first byte ( top of the stack ), which has the index number of the ni address stored in the router 44 . for the purposes of illustration the value is 5 . the router then checks in the local router interface table for corresponding ni address towards the source workstation or device 41 . this byte of header information will be discarded . then router 44 , encapsulates the new frame with the new ( shrunk or modified ) roacm header , where one byte is dropped ( the value ‘ 5 ’), and re - add only the 2 - bit control field with same value ‘ 10 ’, as shown in fig6 b . therefore , one will have in the new roacm header , only two bytes and again at the top of the stack is 2 - bit control field . in the next hop , router 43 , extracts and checks the first two bits and then the first byte and gets the corresponding ni address stored locally in the router 43 . again , router 43 , will discard this byte of header information ( the value ‘ 3 ’) after finding the corresponding ni address , and adding back the 2 - bit control field with same value at the top of the stack . after the new roacm header is encapsulated with the current destination ni address , it will be sent for the next hop . in this case , only 2 - bit and one byte are left for the last hop , as shown in fig6 c . the remaining byte is the index number for the ni address for the source workstation 41 . at the last hop , router 42 , does the same process that it extracts and checks the control field and the remaining one byte header . then , router 42 , gets the current ni address , discards the byte of header ( the value ‘ 1 ’, but will keep the control bit ), and re - encapsulates the ip packet , as shown in fig6 d . once the ip packet reaches the source workstation 41 , it knows that this is the ack for the connection , and store the information locally as illustrated in fig1 , and that it will use only the right column 14 ( fig1 ), for forwarding the subsequent ip packets as shown in fig3 . after this , the workstation changes the value of the control field to ‘ 11 ’, so that all routers and the destination workstation have information that it is the data transmission stage . then , it encapsulates the right side column 14 ( fig1 ), 54 ( fig5 ), with the values ‘ 4 ’,‘ 6 ’,‘ 8 ’, and put in the dlh its source mac address and destination mac address ( belongs to the edge router ), then it sends the ip packet to router 42 , where the same process performed in the backward direction also will be employed for the forward direction until all data is transferred . it should be appreciated that roacm implemented at the ip / network / transmission level can contain protocol - specific addresses rather than mac / hardware addresses . for some applications the ip packets may encounter a combination of different network devices such as routers , frame relay , mpls , atm switches , . . . etc . in frame relay switches , the process would be the same as the routers , but in the atm switches there is a change in the process . atm uses cells where each cell consists of 48 bytes for the data and 5 bytes for the header . when the ip packet reaches an ingress atm switch ( node ), it will be chopped off to many cells . in this case , the atm switch should extract the roacm header from the ip packet and attach the same roacm to each cell belongs to that particular ip packet . then the same process will be employed on the cells to collect the roacm information ( for atm environment ). once the cells reaches the egress atm switch where the ip packet reassembling takes place , then only one copy of the roacm ( in all cells would be the same ) is inserted in the ip packet . in the coming back trip , and when the ip packet reached the atm switch , only one copy is inserted into all cells , which belongs to that particular ip packet . at the other end ( ingress node ) also one copy of the roacm is inserted in the reassembled ip packet . another option is to do nothing in the atm environment . transparency can be provided without losing interoperability by appending the roacm header to the ip packet ( before the link - level protocol tail ). as most firewalls / operating systems will ignore tail data ( as it is usually treated as padding and similar ), a packet will go up the operating system &# 39 ; s tcp / ip stack and be processed as usual . the down - side of this model is that only paths containing roacm support will be optimized . the roacm invention can be implemented not only on the routers , but also on any switching device , such as , for example , mpls , frame relay , atm , or any other packet switching device , to name a few . similarly , this invention can also work with a hybrid switching device . while the present invention has been particularly described in conjunction with a specific preferred embodiment , it is evident that many alternatives , modifications and variations will be apparent to those skilled in the art in light of the foregoing description . it is therefore contemplated that the appended claims will embrace any such alternatives , modifications and variations as falling within the true scope and spirit of the present invention .