CA2130412C - General transport layer gateway for heterogeneous networks - Google Patents
General transport layer gateway for heterogeneous networksInfo
- Publication number
- CA2130412C CA2130412C CA002130412A CA2130412A CA2130412C CA 2130412 C CA2130412 C CA 2130412C CA 002130412 A CA002130412 A CA 002130412A CA 2130412 A CA2130412 A CA 2130412A CA 2130412 C CA2130412 C CA 2130412C
- Authority
- CA
- Canada
- Prior art keywords
- sptn
- mptn
- header information
- gateway
- protocol
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
Abstract
A multiprotocol transport network (MPTN) gateway provides transparent interconnection of two or more SPTNs running different transport layer protocols to form an integrated heterogeneous MPTN. The MPTN gateway of the present invention has no dependencies on the particular transport protocols running on the SPTNs being interconnected as it utilizes a common transport provider (a GatewayServices Protocol Boundary (GSPB)) between the SPTN transport protocols and the gateway components . The MPTN gateway supports connections between end systems across multiple intermediate networks. The MPTN gateway provides automatic routing based on dynamic participation in the routing protocols of the interconnected SPTNs so that any number of gateways may be interconnected and in any topology desired. As the MPTN gateway has a general architecture and acquires routing information automatically, it supports not only other MPTN nodes and gateways but also non-MPTN nodes and gateways.
Description
2130~12 ,,, :, GENERAL TRANSPORT LAYER GATEWAY FOR
HETEROGENEOUS NETWORKS
BACKGROUND OF THE lNVL.. llON :
I. Field of the Invention The present invention relates to data ~ stions and, more particularly, to a gateway which provides transparent interconnection of two or more nel..olhsrunning different protocols.
II. Back~round and Prior Art ;
Asl~ cAt;~nQnetworkhaveevolved,independentsuppliersofcomputer e and software developed different, non-~n ~tihle formats and protocols for l~ v,lh~ data through the ,~ ~n~Atinnc network~ Yr ,1,~ of well-knowncommuni~tinncprotocolsincludeSystemNetworkArchitecture (SNA), Digital ' N~tnJ.h A~chllecluLe (DECNet), Transmission Control Protocol/Internet Protocol(TCP/IP), NetBIOS and OSI.
, .: ,: -. .
As nel~Jrh~ have grown, and particularly as local area nel~.J.hs (LANs) have come into ~.lde2~read use, many oI~rnis-tinnq have ended up with one or more ~h~.,l~l n~l..J.k~ that are confedvl~llons of one or more logical nel~.J.k~, each logi¢al ~vl~.J.k running a different n~l~.o.l~ g protocol. (A logical ~ l..o.l~ runs single nvl~.o.klug protocol and is ref~..~d to as a single protocol transport n.t~.J.~, or SPTN.) For _ le, a single o~"n;7-t;~n may have dozens of SPTNs u~h~ as many as four or five ~re ~,nt nel~.Jl~g protocols. (Such a physical network having more than one logical network, or SPTN, is termed a hvtv...~bnec,us network. ) Thi8 hvte~o~vu~-ilY!~ fltç~ n jnfltil:~n~: a8 di8tl~uted program8 are generally written for a particular app~ tinn prog~ramming interface (API) which -2130~12 assumes a specific networking protocol, and can, therefore, only run on limited parts of the overall physical network.
In a node, if a mismatch exists between the transport protocols (the most basic end-to-end n~l..orl~ g protocols for opening and closing connections, sen iin~ and receiving data on connections, and sçnt~inp~ and receiving datagrams) assumed bythe particular application programming interface (API) for a company's app1i- fltion program and the transport protocols actually imrl~ ted in one or more of the SPTNs on which the company would like to transport the application data, compçncfltinn between the API and the transport provider may be required. This is described in greater detail in closely related U. S. Patent No. 5,224,098, entitled " C - - -- - - tinn for Mismatched Transport Protocols in a Data C nirAtion Network"
and A~sign~d to the A~ e of the present application.
In addition, there are addressing problems associated with the heterogeneous ne~l~.J.hh. A program today identifies itself and finds its partners using addl~ sse~
r--- ~ ted with a particular n~ g protocol. (A ne~ .killg protocol uses add,~3~3e~ to locate pl~ in the SPTN via existing protocol-bl.e. ~ic means, suchas local ~ tu. ~ searches or dil 7_lul ~ broadcasts, and to route to those pl JKl ~ . ) In order for the program to operate over multiple, different nel~.o~;ki"g protocols, such as in a het~ ~neous network, a ~ - is needed to bridge the gap bt,l~ n, the speoific address set used by the program and the address sets used by the nel~ .klll~ protocols. In particular, program indep~nd~n~ e from specific net~
work pl~tocol~ lB~lui~ a transport-independent --hAn; for finding the source and destination application plOg~ and the cul-~Ls~on~iing available transport pl~tocols. In addition, a me~ hAni~ for selecting t_e best transport protocol toutilize, when multiple nel.. ~llg protocols are available, is lL~lul~ d.
Where there are a number of SPTNs runnir~g different protocols, a igateway provides transparent interconnection of the SPTNs so that a single multiprotocol 2130~12 RA9-92-027X 3 ~ ~
":' transport network, or MPTN, i8 formed. Thi6 MPTN appears to the end user applications, as if a single protocol was used throughout the heterogeneous network Gateways, among other things, provide routing functions in order to enable resources to be located and to relay data between the SPTNs to achieve end-to-end connectivity.
Present gateways, however, have many limitations making the interconnection of n~.J~hs running different protocols non-transparent, if the interconnection is even po~ih ha. For instance, present gateways are transport layer protocol-specific. An çY~ le of a transport layer protocol-specific gateway is one which i8 able to interconnect a network running one flavor of OSI with another network running another flavor of OSI. This gateway is not able to interconnect other types of net~.ol~s, for ÇYr ~ la a network running TCP/IP and a network running SNA.
More detail is fiven on an OSI gateway in an article entitled "An Approach to CO/CL ~ -Internel~,.o~ .g", CO/CL Internel~.o~ g Workshop, July 24-26, 1990.
Another problem with pl ~ sent gateways is that a - ~ of two nel~. J~ may be interconnected, i.e., one gateway being used between the two intelcolmected ~;
n -l~.o.h~. No additional nel~ a may be added so that one continuous h.3t~ a~J~-a network may be formed.
.: . -Further, with current gateway solutions, all nodes in an SPTN must be upgrEIded to include additional functions and protocols in order to operate with the ~0~ . This is not feasible in many environments due to the large number of nodes and cost.
There is a need for a transport layer gateway that has a general architecture so that it has no ~lapçnden~iss on the transport protocols being ~u~ led by the l.ltel~onnected nel..o;~s. Also, there! is a ~ uil, -t for such a ~t~ y to support connectivity across multiple SPTNs. This gateway should also support ' - .:
~130~12 existing nodes running existing protocols that cannot be upgraded to include newfunctions .
SUlla~ARY OF THE INVENTION
A multiprotocol transport nel..~nl~lng (MPTN) gateway provides transparent interconnection of two or more SPTNs running different transport layer protocols to form an integrated heterogenec,us MPTN. The MPTN gateway of the present invention has no depen-lan~iRs on the particular transport protocols running on the SPTNs being interconnectec1 as it utilizes a common interface (a Gateway Services Protocol Boundary (GSPB)) b~l~.een the SPTN transport protocols and the gateway ts. The MPTN gateway supports connact;nnc between end systems across multiple int~ te n~ ,.ks. The MPTN gateway provides autc ' c routing based on dynamic participation in the routing pl otocols of the interconnected SPTNs so that any numbêr of gateways may be interconnected and in any topology desired.
As the MPTN gateway has a general archile~,lul3 and acquires routing info~ t-aul ~ ly, it su~o~ t~ not only other MPTN nodes and ~t~ .y~j but also non~MPTN nodes and gateways.
BRIEF DESCRIPTION OF THE DRAWINGS
While the techni~l description cor ~ludas with claims particularly pointing out and distinctly ,-' ' ' g that which is regarded as the invention, details of a p .,f~,~.ed embodiment of the invention may be more readily ascertained from thefollowing te~hni~l description when read in con~unction with the ~ nying d~awings, where:
Fig. 1 is a diagram illustrating a multiprotocol transport network (MPTN) consisting of a number of single protdcdl transport ne l~. ~ 1 h:i ( SPTNs ) interconnected by NPTN gateways of the present invent on.
, ~ , .
~ 9~' 2130~12 Fig. 2 depicts the MPTN gateway of the present invention in block diagram form.
Fig. 3 depicts the basic format of a basic link unit (BLU) which is received by the MPTN gateway of the present invention from a native node.
Fig. 4 depicts the basic format of a BLU which is received by the MPTN
gateway of the present invention from an MPTN node.
- :'' Fig. 5 illustrates the flow of messages and other information fp~fr~hnn~ed between a native node on an SPTN and the various elements of the MPTN gateway when the native node issues a native search request. Fig. 5A illustrates, in flow chart form, the procedure followed by the Routing Services Element when routing information is requested.
Figs. 6A and 6B illustrate the flow of messages and other infu~ tinr q~ hAnged bel~"..3c,n an MPTN gateway, a native node on an SPTN and the VtlL;oU8elements of the MPTN gateway when the MPTN gateway issues an MPTN search request.
Fig. 7 illustrates the flow of messages and other il ful tion ç~r~h~n"Jed b~l".30n a native node on an SPTN and the various elements of the MPTN gateway when the native node is adveltl,~ g routing infol -tinn to the MPTN Gateway.
Fig. 8 illustrates the flow of messages and other information e~ hAnged bel~,.3en a native node on an SPTN and the various elements of the MPTN gateway when the MPTN gateway is adve~ g routing information to the native node.
Fig. 9 ill,,~ tes the flow of messages and other infu~ tinn ç~rnhAnged be,l-".3en nodes on the SPTNs and the various elements of the MPTN gateway during ,'"' , ' . ':~,.''" ' :' ~130~12 RA9-92-0~7X 6 the conveyance of a datagram between a Native Node on one SPTN and another node on another SPTN .
Fig. 10 illustrates the flow of messages and other information ~rçh~nged bel~ nodes on the SPTNs and the various elements of the MPTN gateway during - ~ ;
the conveyance of a datagram between an MPTN node on one SPTN and another node on another SPTN. -Figs. 11a and 11b illustrate the flow of messages and other info~ ~ti~n ~h~nEed beL~ n nodes on the SPTNs and the various elements of the MPTN
gateway during the establich ~t of a connection between a Native Node on one SPTN and another node on another SPTN.
DETAILED DESCRIPTION OF THE PREFERRED El!~BODIM~T
Figure 1 i~ a high-level block diagram of a multiprotocol transport network (MPTN) 10 consisting of five independent single protocol transport n~
(SPTNs): an OSI SPTN (N09I 12), a TCP/IP SPTN (NTCP 14), an SNA SPTN (N8"" 16), a NatBIOS SPTN (NI~ I09 18), and a second SNA SPTN (N9~", 19). Each SPTN
~1 1~ a different ~ fltinn protocol. In particular, in thi8 ~~~~~ ' '- NO8I12 ' ts the OSI ~n niCflti'n protocol stack, N~cp 14 operates under the TCP/IP protocol~ N9",~ 16 operates using the SNA ~ flti~n protocol, and 80 forth.
Each of the SPTNs has nodes connected thereto. In particular, N08I 12 has nodes ND1 20 and ND2 21, N~cp 14 has node ND3 22, N91~A 16 has node ND4 23, N~ t8Io8 18 has node ND5 24 and N9",~ 19 has nodes ND6 25 and ND7 26. For ~ ity~ each SPTN is shown having only one or two nodes but in reality can have any number of ~ -nodes .
:: ' . . '. ', .'.
-.~: :.:,:
.:: ' .;
Some of these nodes are MPTN access nodes while others are non-MPTN access nodes or native nodes. MPTN access nodes are discussed in great detail in U. S.
Patent No. 5,224,098. In the figure, there are three MPTN Access Nodes, NDl 20, ND5 24 and ND6 25. For the purposes of this specification, an MPTN access node is an end node which allows a first transport user (29a, for Q~ p1Q) conforming to a particular protocol interface definition, SNA, in this example, to use a transport provider (31a) conforming to a different protocol interface definition, OSI, forconveying info~ -tion over an MPTN to another transport user (29c) conforming tothe first transport user's protocol interface definition (SNA) . This ~ ication may be over any number of SPTNs and protocols and is shown in Figure 1 as dashedline 33a. As can be seen, the Ic-- ~ir~tion between NOSI and NN~ is conveyed by an MPTN gateway (GWl 30) which will be discussed in further detail below.
Similarly, some of the nodes are non-MPTN nodes, or native nodes. In the figure, there are four native nodes, ND2 21, ND3 22, ND4 23 and ND7 26. A nativenode for the ~ul~o8e8 of this spe-ifi~ntisn is a node having a transport user 29d which conforms to the same protocol interface definition (OSI, in this example) as its transport provider (31b). Communir~ti~ between a transport user 29d of a native node ND2 21 and another transport user 29e of an MPTN Access Node ND6 25 is shown by dashed line 33b. The vast jo.;ly of presently installed nodes in today's olh~ are native nodes.
. - .: .
Interconnecting the SPTNs NO9I 12, NTCP 14, N3NA 16, NN~ O,18, and N~N~- 19 are MPTN gateways (GWl 30 and GW2 32) of the present invention. The MPTN gateway of the present invention has no depQndQn~iss on the transport protocols being connected, is able to c-~n~ tQn~te two or more SPTNs to form the end-to-end connection, provides ~ut~ tic routing based upon dynamic participation in the routing protocols of the concatenated SPTNs, and supports both MPTN and native nodes.
":''''; ' ''',' ~',''".' .:
HETEROGENEOUS NETWORKS
BACKGROUND OF THE lNVL.. llON :
I. Field of the Invention The present invention relates to data ~ stions and, more particularly, to a gateway which provides transparent interconnection of two or more nel..olhsrunning different protocols.
II. Back~round and Prior Art ;
Asl~ cAt;~nQnetworkhaveevolved,independentsuppliersofcomputer e and software developed different, non-~n ~tihle formats and protocols for l~ v,lh~ data through the ,~ ~n~Atinnc network~ Yr ,1,~ of well-knowncommuni~tinncprotocolsincludeSystemNetworkArchitecture (SNA), Digital ' N~tnJ.h A~chllecluLe (DECNet), Transmission Control Protocol/Internet Protocol(TCP/IP), NetBIOS and OSI.
, .: ,: -. .
As nel~Jrh~ have grown, and particularly as local area nel~.J.hs (LANs) have come into ~.lde2~read use, many oI~rnis-tinnq have ended up with one or more ~h~.,l~l n~l..J.k~ that are confedvl~llons of one or more logical nel~.J.k~, each logi¢al ~vl~.J.k running a different n~l~.o.l~ g protocol. (A logical ~ l..o.l~ runs single nvl~.o.klug protocol and is ref~..~d to as a single protocol transport n.t~.J.~, or SPTN.) For _ le, a single o~"n;7-t;~n may have dozens of SPTNs u~h~ as many as four or five ~re ~,nt nel~.Jl~g protocols. (Such a physical network having more than one logical network, or SPTN, is termed a hvtv...~bnec,us network. ) Thi8 hvte~o~vu~-ilY!~ fltç~ n jnfltil:~n~: a8 di8tl~uted program8 are generally written for a particular app~ tinn prog~ramming interface (API) which -2130~12 assumes a specific networking protocol, and can, therefore, only run on limited parts of the overall physical network.
In a node, if a mismatch exists between the transport protocols (the most basic end-to-end n~l..orl~ g protocols for opening and closing connections, sen iin~ and receiving data on connections, and sçnt~inp~ and receiving datagrams) assumed bythe particular application programming interface (API) for a company's app1i- fltion program and the transport protocols actually imrl~ ted in one or more of the SPTNs on which the company would like to transport the application data, compçncfltinn between the API and the transport provider may be required. This is described in greater detail in closely related U. S. Patent No. 5,224,098, entitled " C - - -- - - tinn for Mismatched Transport Protocols in a Data C nirAtion Network"
and A~sign~d to the A~ e of the present application.
In addition, there are addressing problems associated with the heterogeneous ne~l~.J.hh. A program today identifies itself and finds its partners using addl~ sse~
r--- ~ ted with a particular n~ g protocol. (A ne~ .killg protocol uses add,~3~3e~ to locate pl~ in the SPTN via existing protocol-bl.e. ~ic means, suchas local ~ tu. ~ searches or dil 7_lul ~ broadcasts, and to route to those pl JKl ~ . ) In order for the program to operate over multiple, different nel~.o~;ki"g protocols, such as in a het~ ~neous network, a ~ - is needed to bridge the gap bt,l~ n, the speoific address set used by the program and the address sets used by the nel~ .klll~ protocols. In particular, program indep~nd~n~ e from specific net~
work pl~tocol~ lB~lui~ a transport-independent --hAn; for finding the source and destination application plOg~ and the cul-~Ls~on~iing available transport pl~tocols. In addition, a me~ hAni~ for selecting t_e best transport protocol toutilize, when multiple nel.. ~llg protocols are available, is lL~lul~ d.
Where there are a number of SPTNs runnir~g different protocols, a igateway provides transparent interconnection of the SPTNs so that a single multiprotocol 2130~12 RA9-92-027X 3 ~ ~
":' transport network, or MPTN, i8 formed. Thi6 MPTN appears to the end user applications, as if a single protocol was used throughout the heterogeneous network Gateways, among other things, provide routing functions in order to enable resources to be located and to relay data between the SPTNs to achieve end-to-end connectivity.
Present gateways, however, have many limitations making the interconnection of n~.J~hs running different protocols non-transparent, if the interconnection is even po~ih ha. For instance, present gateways are transport layer protocol-specific. An çY~ le of a transport layer protocol-specific gateway is one which i8 able to interconnect a network running one flavor of OSI with another network running another flavor of OSI. This gateway is not able to interconnect other types of net~.ol~s, for ÇYr ~ la a network running TCP/IP and a network running SNA.
More detail is fiven on an OSI gateway in an article entitled "An Approach to CO/CL ~ -Internel~,.o~ .g", CO/CL Internel~.o~ g Workshop, July 24-26, 1990.
Another problem with pl ~ sent gateways is that a - ~ of two nel~. J~ may be interconnected, i.e., one gateway being used between the two intelcolmected ~;
n -l~.o.h~. No additional nel~ a may be added so that one continuous h.3t~ a~J~-a network may be formed.
.: . -Further, with current gateway solutions, all nodes in an SPTN must be upgrEIded to include additional functions and protocols in order to operate with the ~0~ . This is not feasible in many environments due to the large number of nodes and cost.
There is a need for a transport layer gateway that has a general architecture so that it has no ~lapçnden~iss on the transport protocols being ~u~ led by the l.ltel~onnected nel..o;~s. Also, there! is a ~ uil, -t for such a ~t~ y to support connectivity across multiple SPTNs. This gateway should also support ' - .:
~130~12 existing nodes running existing protocols that cannot be upgraded to include newfunctions .
SUlla~ARY OF THE INVENTION
A multiprotocol transport nel..~nl~lng (MPTN) gateway provides transparent interconnection of two or more SPTNs running different transport layer protocols to form an integrated heterogenec,us MPTN. The MPTN gateway of the present invention has no depen-lan~iRs on the particular transport protocols running on the SPTNs being interconnectec1 as it utilizes a common interface (a Gateway Services Protocol Boundary (GSPB)) b~l~.een the SPTN transport protocols and the gateway ts. The MPTN gateway supports connact;nnc between end systems across multiple int~ te n~ ,.ks. The MPTN gateway provides autc ' c routing based on dynamic participation in the routing pl otocols of the interconnected SPTNs so that any numbêr of gateways may be interconnected and in any topology desired.
As the MPTN gateway has a general archile~,lul3 and acquires routing info~ t-aul ~ ly, it su~o~ t~ not only other MPTN nodes and ~t~ .y~j but also non~MPTN nodes and gateways.
BRIEF DESCRIPTION OF THE DRAWINGS
While the techni~l description cor ~ludas with claims particularly pointing out and distinctly ,-' ' ' g that which is regarded as the invention, details of a p .,f~,~.ed embodiment of the invention may be more readily ascertained from thefollowing te~hni~l description when read in con~unction with the ~ nying d~awings, where:
Fig. 1 is a diagram illustrating a multiprotocol transport network (MPTN) consisting of a number of single protdcdl transport ne l~. ~ 1 h:i ( SPTNs ) interconnected by NPTN gateways of the present invent on.
, ~ , .
~ 9~' 2130~12 Fig. 2 depicts the MPTN gateway of the present invention in block diagram form.
Fig. 3 depicts the basic format of a basic link unit (BLU) which is received by the MPTN gateway of the present invention from a native node.
Fig. 4 depicts the basic format of a BLU which is received by the MPTN
gateway of the present invention from an MPTN node.
- :'' Fig. 5 illustrates the flow of messages and other information fp~fr~hnn~ed between a native node on an SPTN and the various elements of the MPTN gateway when the native node issues a native search request. Fig. 5A illustrates, in flow chart form, the procedure followed by the Routing Services Element when routing information is requested.
Figs. 6A and 6B illustrate the flow of messages and other infu~ tinr q~ hAnged bel~"..3c,n an MPTN gateway, a native node on an SPTN and the VtlL;oU8elements of the MPTN gateway when the MPTN gateway issues an MPTN search request.
Fig. 7 illustrates the flow of messages and other il ful tion ç~r~h~n"Jed b~l".30n a native node on an SPTN and the various elements of the MPTN gateway when the native node is adveltl,~ g routing infol -tinn to the MPTN Gateway.
Fig. 8 illustrates the flow of messages and other information e~ hAnged bel~,.3en a native node on an SPTN and the various elements of the MPTN gateway when the MPTN gateway is adve~ g routing information to the native node.
Fig. 9 ill,,~ tes the flow of messages and other infu~ tinn ç~rnhAnged be,l-".3en nodes on the SPTNs and the various elements of the MPTN gateway during ,'"' , ' . ':~,.''" ' :' ~130~12 RA9-92-0~7X 6 the conveyance of a datagram between a Native Node on one SPTN and another node on another SPTN .
Fig. 10 illustrates the flow of messages and other information ~rçh~nged bel~ nodes on the SPTNs and the various elements of the MPTN gateway during - ~ ;
the conveyance of a datagram between an MPTN node on one SPTN and another node on another SPTN. -Figs. 11a and 11b illustrate the flow of messages and other info~ ~ti~n ~h~nEed beL~ n nodes on the SPTNs and the various elements of the MPTN
gateway during the establich ~t of a connection between a Native Node on one SPTN and another node on another SPTN.
DETAILED DESCRIPTION OF THE PREFERRED El!~BODIM~T
Figure 1 i~ a high-level block diagram of a multiprotocol transport network (MPTN) 10 consisting of five independent single protocol transport n~
(SPTNs): an OSI SPTN (N09I 12), a TCP/IP SPTN (NTCP 14), an SNA SPTN (N8"" 16), a NatBIOS SPTN (NI~ I09 18), and a second SNA SPTN (N9~", 19). Each SPTN
~1 1~ a different ~ fltinn protocol. In particular, in thi8 ~~~~~ ' '- NO8I12 ' ts the OSI ~n niCflti'n protocol stack, N~cp 14 operates under the TCP/IP protocol~ N9",~ 16 operates using the SNA ~ flti~n protocol, and 80 forth.
Each of the SPTNs has nodes connected thereto. In particular, N08I 12 has nodes ND1 20 and ND2 21, N~cp 14 has node ND3 22, N91~A 16 has node ND4 23, N~ t8Io8 18 has node ND5 24 and N9",~ 19 has nodes ND6 25 and ND7 26. For ~ ity~ each SPTN is shown having only one or two nodes but in reality can have any number of ~ -nodes .
:: ' . . '. ', .'.
-.~: :.:,:
.:: ' .;
Some of these nodes are MPTN access nodes while others are non-MPTN access nodes or native nodes. MPTN access nodes are discussed in great detail in U. S.
Patent No. 5,224,098. In the figure, there are three MPTN Access Nodes, NDl 20, ND5 24 and ND6 25. For the purposes of this specification, an MPTN access node is an end node which allows a first transport user (29a, for Q~ p1Q) conforming to a particular protocol interface definition, SNA, in this example, to use a transport provider (31a) conforming to a different protocol interface definition, OSI, forconveying info~ -tion over an MPTN to another transport user (29c) conforming tothe first transport user's protocol interface definition (SNA) . This ~ ication may be over any number of SPTNs and protocols and is shown in Figure 1 as dashedline 33a. As can be seen, the Ic-- ~ir~tion between NOSI and NN~ is conveyed by an MPTN gateway (GWl 30) which will be discussed in further detail below.
Similarly, some of the nodes are non-MPTN nodes, or native nodes. In the figure, there are four native nodes, ND2 21, ND3 22, ND4 23 and ND7 26. A nativenode for the ~ul~o8e8 of this spe-ifi~ntisn is a node having a transport user 29d which conforms to the same protocol interface definition (OSI, in this example) as its transport provider (31b). Communir~ti~ between a transport user 29d of a native node ND2 21 and another transport user 29e of an MPTN Access Node ND6 25 is shown by dashed line 33b. The vast jo.;ly of presently installed nodes in today's olh~ are native nodes.
. - .: .
Interconnecting the SPTNs NO9I 12, NTCP 14, N3NA 16, NN~ O,18, and N~N~- 19 are MPTN gateways (GWl 30 and GW2 32) of the present invention. The MPTN gateway of the present invention has no depQndQn~iss on the transport protocols being connected, is able to c-~n~ tQn~te two or more SPTNs to form the end-to-end connection, provides ~ut~ tic routing based upon dynamic participation in the routing protocols of the concatenated SPTNs, and supports both MPTN and native nodes.
":''''; ' ''',' ~',''".' .:
2~ 30~12 Figure 2 illustrates the MPTN Gateway 30 of the present invention in block diagram form connected to SPTNs NogI 12, NTCP 14, N8~,~ 16 and N~ t~Io8 18. Gateway 30 consists of a plurality of Transport Providers TPrO9I 34a, TPr~cp 34b, TPrE,N" 34c and TPrN~t~IOs 34d. These Transport Providers define the transport protocols that are actually implemented when data is exchanged between nodes (or gateways) on one SPTN, plus new MPTN protocols (or deltas) to support non-MPTN nodes . In this eY~p1e, TPrO9I irr~pl~ -nts the TCP protocol plus deltas, and so forth. Each of the Transport Providers performs all of the transport provider-specific functions in the MPTN Gateway. Only four Transport Providers are shown although any number of providers may be ~ ~ nted in Gateway 30.
MPTN Gateway 30 further consists of an MPTN General Services Element 36 which is logically connected to each of the Transport Providers. MPTN General Services Element 36 provides various services for the Gateway 30, none of which are transpcrt protocol-specific . MPTN General Services Element 36 is separated from the Transport Providers by a Gateway Services Protocol Boundary (GSPB) 38 which defines the interface b~l~.e3n the Transport Providers 34a, 34b, 34c, and 34d and the MPTN General Services Element 36. Above the GSPB, no transport protocol-spe-~i~o functlons occur.
The use of the GSPB is important for a number of reasons. First, separating ~ ~
the MPTN General Services Element from the specific Transport Providers allows the ; ~ ~;
MPTN General Services Element to be in~lep~nd~nt from the underlying Transport P~ uv;dv~ 6 .
-: ." ' "~ '' Second, a mapping can be defined from each supported Provider to the GSPB
and vice versa. This allows a much easier definition of mappings bel~.~cll ~u~ul ted Transport Providers. Rather than cl~fining the mapping from each supported ~ -Transport Provider to each other Transport Provider (an O(N2) problem), all that , .- ~ .
; ~:, . .
~ ', :: ~ . ,, , ,, . . , i" , . , , . : - , :
is re(luiLed is to define the mapping from each supported Transport Provider to the general form (an O(N) problem).
Third, enabling a new Transport Provider to be a part of an MPTN gateway is simple. The new Transport Provider merely has to map its transport protocol to the GSPB. This allows a Transport Provider to be installed without requiring changes to the MPTN General Services Element 36.
MPTN General Services Element 36 consists of a number of elements: 1) a Manager 40 for Ins,nngjn~ the activities within the MPTN General Services Element 36;
2) a Gateway Services Element 42 for relaying datagrams and establishing connections through other gateways; and 3) a Routing Services Element 44 for maintaining an address loo~s-up table for determining the location of a requested end user (such as that definecl by the Interdomain Routing Protocol, or IDRP) and for implementing multicast search and verification protocols.
Gateway 30 further consists of a Relay 48 which efficiently relays connections data through the Gateway when a connection is est~bli~h~d between two SPTNs.
Figures 3 and 4 are graphical representations at a high level of the format of a basic link unit (BLU) which is routed throughout the MPTN 10 between MPTN
Access Nodes, MPTN Gateways and Native Nodes. A BLU, for the purposes of this speri~cation, is a packet of information being conveyed b~l~.e~.l the SPTNs via the Gateway. The label given to the BLU is dependent upon the transport provider ~l~tOCOl. For instance, if the BLU is being conveyed upon a frame relay network,it is labeled a "frame". Or, if it is being conveyed via an asynchronous transfer mode (ATM) network, it is labeled a "cell" . All of these various data units are BLUs for the purposes of this invention.
Figure 3 illustrates a BLU as it is received at the MPTN Gateway 30 of the .-'. ' ':
. - .: : . . ::: - : . , . : :
2130~12 kA9-92-027X 10 present invention from a Native Node, such as ND2 21 of Figure 1. Figure 4 illustrates a BLU as it is received at the MPTN Gateway 30 from an MPTN Access Node, such as ND1 20 of Figure 1. Alternatively, the BLU illustrated in Figure 4could be received at an MPTN Access Node from an MPTN Gateway.
As shown in Figure 3, Native Node BLU includes a Transport Provider-specific header and trailer (TPr Hdr, TPr Tlr, respectively). This header and trailer is used for conveying the BLU through the SPTN as is well known in the art. The Transport Protocol header consists of a number of fields: a Command Type field (Comm Type) for idenlifyil~g particular BLU type, i.e., whether it is a datagram or a ~n -nll; a Source Address field (Source Addr) identifying the source transportuser; a Destin~tior~ Address field (Dest Addr) identifying the destination transport user; and a Control field (Ctl) for providing various control functions. Following the Transport Header, a Transport User Payload field (T User Payload) which holds the data that is to be conveyed between the source and the destin~tinn transport --~
users .
. .'',.. '' :.':
As shown in Figure 4, MPTN BLU, like Native Node BLU, in~lul1es a ~ -Transport Provider-specific header and trailer. As was noted, this header and trailer is used for conveying the BLU through the SPTN as is well known in the art.
' ," ',".',:
The BLU also includes an MPTN header for providing n~cesS~ry inful Sinn to the MPTN Gateway or Access Node. MPTN header consists of a length field (Len)in~ ting the length of the BLU. It also has a ~c -nd-type field (Comm) for ~ ~~ntli~ting the type of BLU, i.e., whether the BLU is a In nd such as Register, -; i Locate or Connect, or whether it is a datagram for forwarding. A routing info. tinn field (RI) contains the destination address and the source address of the -~
destin~t;nn and source tr~nsport users. A control information field (Ctl Info) provides various BLU information such as "time to live", segment spel~ific~tinn 2130~2 indicating how the BLU should be rQ~sernhled if it has been disassembled during conveyance, etc.
The BLU further has a transport user payload (T User Payload) which holds the data that is to be conveyed between the source and the destination transportusers.
Routing in an MPTN environment involving an MPTN Gateway can be broken into three pieces:
1) from the source node to the first MPTN Gateway. If the source node is an MPTN node (such as path 33a (Fig. 1) from NDl 20 to GWl 30), routing from the source to the first MPTN Gateway uses MPTN Protocols. If the source node a native, or non-MPTN node, (such as path 33b (Fig. 1) from ND2 21 to GWl 30) routing to the first MPTN Gateway uses the native protocols of the transport provider.
2) between one or more MPTN Gateways (such as path 33b (Fig. 1) from GWl 30 to GW2 32). Routing between MPTN Gateways always uses MPTN protocols.
MPTN Gateway 30 further consists of an MPTN General Services Element 36 which is logically connected to each of the Transport Providers. MPTN General Services Element 36 provides various services for the Gateway 30, none of which are transpcrt protocol-specific . MPTN General Services Element 36 is separated from the Transport Providers by a Gateway Services Protocol Boundary (GSPB) 38 which defines the interface b~l~.e3n the Transport Providers 34a, 34b, 34c, and 34d and the MPTN General Services Element 36. Above the GSPB, no transport protocol-spe-~i~o functlons occur.
The use of the GSPB is important for a number of reasons. First, separating ~ ~
the MPTN General Services Element from the specific Transport Providers allows the ; ~ ~;
MPTN General Services Element to be in~lep~nd~nt from the underlying Transport P~ uv;dv~ 6 .
-: ." ' "~ '' Second, a mapping can be defined from each supported Provider to the GSPB
and vice versa. This allows a much easier definition of mappings bel~.~cll ~u~ul ted Transport Providers. Rather than cl~fining the mapping from each supported ~ -Transport Provider to each other Transport Provider (an O(N2) problem), all that , .- ~ .
; ~:, . .
~ ', :: ~ . ,, , ,, . . , i" , . , , . : - , :
is re(luiLed is to define the mapping from each supported Transport Provider to the general form (an O(N) problem).
Third, enabling a new Transport Provider to be a part of an MPTN gateway is simple. The new Transport Provider merely has to map its transport protocol to the GSPB. This allows a Transport Provider to be installed without requiring changes to the MPTN General Services Element 36.
MPTN General Services Element 36 consists of a number of elements: 1) a Manager 40 for Ins,nngjn~ the activities within the MPTN General Services Element 36;
2) a Gateway Services Element 42 for relaying datagrams and establishing connections through other gateways; and 3) a Routing Services Element 44 for maintaining an address loo~s-up table for determining the location of a requested end user (such as that definecl by the Interdomain Routing Protocol, or IDRP) and for implementing multicast search and verification protocols.
Gateway 30 further consists of a Relay 48 which efficiently relays connections data through the Gateway when a connection is est~bli~h~d between two SPTNs.
Figures 3 and 4 are graphical representations at a high level of the format of a basic link unit (BLU) which is routed throughout the MPTN 10 between MPTN
Access Nodes, MPTN Gateways and Native Nodes. A BLU, for the purposes of this speri~cation, is a packet of information being conveyed b~l~.e~.l the SPTNs via the Gateway. The label given to the BLU is dependent upon the transport provider ~l~tOCOl. For instance, if the BLU is being conveyed upon a frame relay network,it is labeled a "frame". Or, if it is being conveyed via an asynchronous transfer mode (ATM) network, it is labeled a "cell" . All of these various data units are BLUs for the purposes of this invention.
Figure 3 illustrates a BLU as it is received at the MPTN Gateway 30 of the .-'. ' ':
. - .: : . . ::: - : . , . : :
2130~12 kA9-92-027X 10 present invention from a Native Node, such as ND2 21 of Figure 1. Figure 4 illustrates a BLU as it is received at the MPTN Gateway 30 from an MPTN Access Node, such as ND1 20 of Figure 1. Alternatively, the BLU illustrated in Figure 4could be received at an MPTN Access Node from an MPTN Gateway.
As shown in Figure 3, Native Node BLU includes a Transport Provider-specific header and trailer (TPr Hdr, TPr Tlr, respectively). This header and trailer is used for conveying the BLU through the SPTN as is well known in the art. The Transport Protocol header consists of a number of fields: a Command Type field (Comm Type) for idenlifyil~g particular BLU type, i.e., whether it is a datagram or a ~n -nll; a Source Address field (Source Addr) identifying the source transportuser; a Destin~tior~ Address field (Dest Addr) identifying the destination transport user; and a Control field (Ctl) for providing various control functions. Following the Transport Header, a Transport User Payload field (T User Payload) which holds the data that is to be conveyed between the source and the destin~tinn transport --~
users .
. .'',.. '' :.':
As shown in Figure 4, MPTN BLU, like Native Node BLU, in~lul1es a ~ -Transport Provider-specific header and trailer. As was noted, this header and trailer is used for conveying the BLU through the SPTN as is well known in the art.
' ," ',".',:
The BLU also includes an MPTN header for providing n~cesS~ry inful Sinn to the MPTN Gateway or Access Node. MPTN header consists of a length field (Len)in~ ting the length of the BLU. It also has a ~c -nd-type field (Comm) for ~ ~~ntli~ting the type of BLU, i.e., whether the BLU is a In nd such as Register, -; i Locate or Connect, or whether it is a datagram for forwarding. A routing info. tinn field (RI) contains the destination address and the source address of the -~
destin~t;nn and source tr~nsport users. A control information field (Ctl Info) provides various BLU information such as "time to live", segment spel~ific~tinn 2130~2 indicating how the BLU should be rQ~sernhled if it has been disassembled during conveyance, etc.
The BLU further has a transport user payload (T User Payload) which holds the data that is to be conveyed between the source and the destination transportusers.
Routing in an MPTN environment involving an MPTN Gateway can be broken into three pieces:
1) from the source node to the first MPTN Gateway. If the source node is an MPTN node (such as path 33a (Fig. 1) from NDl 20 to GWl 30), routing from the source to the first MPTN Gateway uses MPTN Protocols. If the source node a native, or non-MPTN node, (such as path 33b (Fig. 1) from ND2 21 to GWl 30) routing to the first MPTN Gateway uses the native protocols of the transport provider.
2) between one or more MPTN Gateways (such as path 33b (Fig. 1) from GWl 30 to GW2 32). Routing between MPTN Gateways always uses MPTN protocols.
3) from the last MPTN Gateway to the destination node (such as path 33b (Fig.
1) from GW2 32 to ND6 25). If the destination node is an MPTN node (such as ND6 25 (Fig. 1)), routing from the last MPTN Gateway to the destination uses MPTN
Protocols. Where the destin~tion node is a native, or non-MPTN node, (such as ND7 26 (Fig. 1) ), routing from the last MPTN Gateway to the destination uses the native protocols of the transport provider.
In supporting non-MPTN nodes, the MPTN gateway must support transport pl~vide.~ that use both search based and routing-table based routing. With ~earch based transport providers, the route from the source to the destin~ti-ln is not known at the time the connection request is made (or datagram is sent). A search is conducted to find where the destination is located, and then the route to the dest;nsti~-n is calculated . Transport providers that use search based routing include protocols for searching for~the requested destination and calculating the best route once the destin~tir~n is found. ~r~mrlRs of search based transport providers include ~ ~ ,;,.,,- :
.- ........
NetBIOS and SNA.
With a routing table based protocol, the route to the destination is known before the connection request is made (or datagram sent) . When a connection request is made (or datagram sent), the routing table in the node points to the "next hop"
along the path in routing the request to the destination. Transport providers that use a routing table based protocol include routing protocols for building the "next hop" routing tables and for maintaining the routing tables. Examples of routing table based transport providers include OSI and TCP/IP. - ~
':' '' ' '-To support transport providers that use a search based protocol, the MPTNGateway must participate in the search and route calculation protoc~ls. This involves a number of changes, or deltas, to the transport provider. This is shown in Fig. 5 where a native search request is received by MPTN Gateway 30 from a native node on SPTN 1 at 100. At 101, Transport Provider 1 parses the transport protocol ~e~ :ric header and det.,, ~nP~ from the destination address field whether the search request must be forwarded to the MPTN network. If the search is to beforwarded, the transport provider will pass the search request across the GSPB to ~ -~
the Manager. At 10a, the Manager det~ that it is a search request, and f~.. rds the request to Gateway Services. At 103, Gateway Services forwards the ident~ ti~n of the des~:-.P~ n to the Routing Service Element. At 104, Routing Services ~' t returns the address of the "next hop" to Gateway Services Element.In order to dete. ~ - the address of the next hop, the Routing Services Element must perform a ~ of steps. This is shown in Fig. 5A. At 140, the Routing S_. ~lces Element lec~ivas the destinAt;nn address from the Gateway Services F1 t. At 141, the Routing Services Element dete. -- whether the destination can be reached by searching its routing tables for the NetId of the desffnAt;~ naddr~ss. If not, at 142, the Routing Services Element returns a negative response to the requesting native node. If so, at 143, the Routing Services ~l t dete. ~ -- whether the NetId of the destinAtion address is a split NetId (i.e., the ' ~;
- ,:, .
:
RA9-92-027X 13 2 1 3 0 ~ 1 2 , .~: ,~ ,. ..
network is split into two or more disjoint SPTNs and the destination could be in one --of several SPTNs). If not, at 144, the Routing Services Element r~ ,.s the next hop to the requesting native node. If it is a split NetId, at 145, the Routing Services Element determines whether there is a cache entry for the NetId of the destination address . If so, at 146 j the Routing Services Element returns the cached next hop value to the requesting native node. If not, at 147, the Routing Services Element initiates a search of each potential SPTN. This is described in copending Cana~lian application no. 2,105,040, filed August 27, 1993, entitled "Inter-Domain Multicast Routing". This procedure detailed in Fig. 5A is used whenever the Routing Services Element is requested by the Gateway Services Element for routing infol ti~n.
Referring again to Fig. 5, once it is detel ~ e~ that the destination can be reached through this MPTN Gateway, General Services Element responds to S
Tranaport Provider 1 with the ~o~ilive search response. This is shown by steps 104-106. At 107, Transport Provider 1 then responds to the original search/verifi- ~at;rn request, stating that the requested destination is located on this MPTN Gateway. The MPTN Gateway will subsequently receive a native connection request (or datagram). This is described below in conjunction with Figure 9.
Figures 6A and 6B illustrate the message flows when an MPTN search is ~eceived from another MPTN Gateway (MPTN GW2) . At 109, a c- nn~cti~n is alreadyesteh~ cl between the two MPTN Gateways and, at 110, Transport Provider 2 r~c~lv~,s a BLU (representing the MPTN search request) from MPTN GW2. At 111, ~;
Transport Provider 2 parses the header and trailer and forwards the MPTN data and cQnn~t;r~r ID to the Manager. Based upon the conn~ct;on ID, the Manager, at 112,fu... - ds the MPTN search request to the Routing Services Element. At 113, the Routing Services Element detel ~ ec that it is an MPTN search request and that the Des~ination NetId is in SPTN1 (to which MPTN GW1 is providing access). !Routing Services Element initiates a search request of SPTN1 at 113. At 114, the Gateway .. .. :
RA9-92-027X 14 ~
.".., ;, Services Element forwards the request to the Manager which, in turn, forwards the request to the Transport Provider 1, at 115. At 116, Transport Provider 1 initiates the native search protocol for the requested destination address.
As shown on Fig. 6B, at 117, Transport Provider 1 receives a positive ;
response to search from SPTN1. At 118, Transport Provider 1 parses the header/trailer and forwards the positive response to the Routing Services Element (via Manager, at 119, and Gateway Services Element, at 120) . The Routing Services Element, at 121, builds a positive response to the MPTN search and sends to the Manager which forwards the positive response to Transport Provider 2 at 122. At 123, Transport Provider 2 forwards the po~ilive response to the requesting MPTN --GW.
Where the MPTN search request needs to be forwarded to another MPTN
Gateway, Gateway Services Element will forward the MPTN search request and next hop Gateway address to Manager, which will forward the search request to the next MPTN Gateway.
To support transport providers that use a routing table based protocols, the MPTN Ga~eway must participate in the routing protocols that build and maintain the -transport provider loulil~g tables. This involves a number of changes, or deltas, to the transport provider. The method of building transport provider routing tables ;
is shown in Fig. 7 while the advertising of transport provider inf~. ti~ln is shown in Fig. 8. -In Fig. 7, at 130, Transport Provider 1 learns of native routing inf". -tion and forwards this i~lfo~ tion to the Manager. At 131, 132 and 133, Transport Provider 1, Manager and Gateway Services Element, respectively, forwards this -11~. t~nn to the Routing Services'~l t. At 134, the Routing Services Element ;
utilizes IDRP protocols to distribute this routing inf~l -tir.n to adjacent MPTN i , . .
:,-;",. ..,: ;.
" ,i~, "
, ~.,.,,.,:
~ ~,, ~,...
2~ 30~2 RA9-92-027X 15 - ~
, ~ , Gateways.
Fig. 8 illustrates the message flows when MPTN Gateway 30 receives routing i -information from an adjacent MPTN Gateway. In general, when the MPTN Gateway receives new routing information ( via the IDRP protocols ), Routing Services Element checks the protocol type of the new routing information to see if it is the same type as any of the SPTNs this Gateway supports. If they do match, the new routing information will be passed across the GSPB into any SPTN that has the same transport protocol type. This process of forwarding MPTN routing information into an SPTN is referred to as advertising. The transport provider then take~i this routing information and propAg~tes it through the SPTN using the native routing protocol of that transport provider. Subsequent native connect requests (or datagrams) whose destinot;nr routing information were advertised this way, will be routed to the MPTN Gateway. The transport provider will receive the connection ;
request (or datagram) and will pass it across GSPB. This is described in Figure 9.
Using the method des-rihed above the MPTN Gateway provides maximum po~ h1 com~e ilivily to native (non-MPTN) nodes that use routing-based ~rotocols.
j , The spe.~if~c message flows for Fig. 8 are as follows. At 135, the Routing Services Element learns the new routing info. tinn and d~t~ that it affects an Attr~ SPTN. The Routing Services Element adv~ ies that info. tinn into ; the ,~ect~,d SPTN. At 136 and 137, the Gateway Services Element and the Manager re~pe-tively forward this info~ tinn to Transport Provider 1. At 138, Transport Provider 1 uses native routing protocols to adv. . l;se the new routing info. tinn .
:''' :
:~ ;
21304~2 Figure 9 illustrates the operation of Gateway GW1 30 (Fig. 2) where a BLU in the form of a datagram, i.e., a connectionless data packet, is to be conveyed between a Native Node on SPTN 1 to a node (Node 2) on SPTN 2. The path from Node 1 to Node 2 traverses Gateway 30. Node 2 could, alternatively, be a gatewayfor interconnection to another SPTN (i.e., SPTN 3). In the figure, the arrows indicate the direction of the flow of messages and the corresponding Native NodeBLU (of the form shown in Figure 3) as it is processed. At 51, the particular Transport Provider receives the BLU from the Native Node on SPTN 1 (to be conveyed to Node 2 on SPTN 2), parses the transport protocol-specific header (and trailer, if any) and d~te~ ~ -9 from the destination addresc~ field that Node 2 is not located in SPTN 1 and needs to be forwarded to another SPTN. The Transport Provider forwards T User Payload to the Manager at 52 with parameters indicatingto the Manager the transport user destination and the source addresses, re~luiled quality of service, user characteristics, and indication that it is a datagram to be forwarded. The Manager forwards the parameters and the T User Payload to the Gateway Services Element at 53 in order to obtain routing information. Gateway Services Element forwards the identifi-~ti~.n of the destination user to the Routing Services Element at 54. Routing Services Element d~tel ~ ~s, from its look-up table (as illustrated in Fig. 5A ii~c~l~sed above), where the destin~tir.n user is located and l~tu~.~S~ at 55, to the Gateway Services Element the "next hop" thereby identifying the particular transport provider address to which the datagram needs to be forwarded, Transport Provider 2, in this eYP le. At 56, the Gateway Services r~ -- t builds an MPTN header to the T_User Payload and forwards the resulting MPTN datagram to the Manager. At 57, Manager forwards the new MPTN
datagram to Transport Provider 2 along with the co..~s~n~ling par to~s to in~ te to the Transport Provider the transport provider source and desffn~tinn add.ecaca of the "next hop", re~luiled quality of service, user characteristics, and in-~ ti-m that it is a datagram for forwarding. The Transport Provider adds the transport protocol-specific header and trailer and transmits the resulting BLU onto SPTN 2 at 58.
~',~, '.' ,~ ,.! '. , " , , . ! .
2130~5~2 Figure 10 illustrates the operation of Gateway 30 where a BLU in the form of a datagram is to be conveyed between an MPTN Node on SPTN 1 to an MPTN node on SPTN 2. The path from Node 1 to Node 2 traverses Gateway 30. At 61, the particular Transport Provider receives the BLU from the MPTN Node on SPTN 1, parses the transport protocol-specific header (and trailer, if any) and determines from the source and destination address fields that the datagram is addressed to the well-known MPTN port on Gateway 30. As is known in the industry, a well-known port is a local address that is reserved for a specific service. Only MPTN datagrams will be addres3ed to this well-known port, thus the Transport Provider knows to forward the MPTN datagram to the Manager. The Transport Provider forwards the MPTN dstagram (which includes the MPTN header and the T User Payload or user datagram), and pal _ tel s to the Manager at 62. From the transport user addresses in the MPTN header, the Manager detel ~ e~ that it is a MPTN datagram for forwarding to another SPTN and forwards the BLU to the Gateway Services Element for routing info. t;- n at 63. Gateway Services Element forwards the ident;fil ~t;on of the destinAt~n user to the Routing Services Element at 64. Routing Services Element determines, from its look-up table (as described in Fig. 5A and e~ nying text), where the destination user is located and returns, at 65, to the Gateway Services Element the "next hop" thereby id~nl~yillg the particular l. .ns~u l provider add-2ss to which the MPTN datagram needs to be forwarded. At66, the Gateway Services Element forwards the MPTN datagram back to the Manager.Manager forwards the MPTN datagram to Transport Provider 2 at 67, along with theCC~.2 3~ ~ing ~Ll tG~S to indicate to the Transport Provider the source and dest;natinr~ transport provider add~e~ses of the next hop and re~ l.e~l quality of service. The Transport Provider adds the transport protocol-specific header and trailer and transmits the BLU onto SPTN 2 at 68.
.; ' -:, Figures lla and llb illustrate the operation of Gateway 30 where a "connect"
le4ue~l BLU is received frdm a Native Node on SPTN 1 requésting to be connected ~ ~ -to an MPTN Node on SPTN 2. The path from Node 1 to Node 2 traverses Gateway 30. ~ ~ -~.,,~,' .' . ". ,,:, RA9-92-027X 18 21~0412 In Figure lla, at 71, the particular Transport Provider receives the BLU from the Native Node on SPTN 1, parses the transport protocol-specific header (and trailer, if any), recop~ni7e~ from the "C,: nd Type" field that it is a "connect request"from the Native Node and determines from the destination address field that the connect request needs to be forwarded to an MPTN Gateway. The Transport Provider forwards the r~ ining portion of the BLU which includes the T User Payload to the Manager at 72 along with parameters giving the source and destination user addresses, required quality of service transport characteristics and a "connect request" parameter. The Manager forwards the parameters to the Gateway Services Element to obtain routing information and to establish the connection to Node 2 at 73.
Gateway Services ~1 t forwards the identification of the destiniati-.n user to the Routing Services Element at 74 . Routing Services Element determines, from its look-up table (Fig. 5A and ~c~ -nying text) and, when necessary, initiates a search of the MPTN network, where the destination user is located and relu~.ls, at 75, to the Gateway Services Element the "next hop" thereby identifying the particular transport provider address to which the "connect request" needs to be forwarded.At 76, the Gateway Services Element builds an MPTN Connect which in~lt~ s the T User ~yload and forwards the resulting "connect request" to the Manager.
Manager forwards the connect request to the Transport Provider 2 at 77, along with the cu..c ~-n~linf~ pal tels to indicate to the Transport Provider the source and dest~nAt~r~n transport provider addresses of the next hop, ra~lui~;d quality of service, and MPTN Connect. The Transport Provider estAhli~ih~s a connection withthe MPTN node on SPTN 2 and sends the MPTN Connect (with transport specific header and trailer) as the first data packet on the connection at 78. At 79, theGateway Services Element sends a message, "Relay Get Ready", to the Manager, forforwarding to the Relay, at 80, to prepare for a connection.
In order for a connection to be estA1)1i~h~, an "end-to-end" confirmation must be estAhli~h~cl so that each "hop" along the connection path is available for estAh1iching the connection. In other words, the "connect request" BLU is - ': ~.;'~
:: ~ .'':
' ,:"''~,," ' ,: ., , . , ., ", , " ,, ~ ~ :
2130~12 ;
forwarded throughout the MPTN to all of the intermediary nodes so that each is prepared for the connection. It is not until a "connect request confirmation" isreceived by the orifinating node that the MPTN connection i8 conQi~fff~fred to be established .
As shown in Figure 11b, at 81, the "MPTN Connect request confirmation" i8 received at Transport Provider 2 from Node 2 on SPTN 2. This "MPTN Connect request COl~il tion" inf~if~f~tes to the Gateway that the connection path i8 ready for user data e~cf hf~nEe. As with all BLUs, the transport-specific header and trailer are parsed, and the ~ fffr MPTN Connect confirmation(with pa, teLf3ff) is forwarded to the Manager for procaQ~ g. The Manager forwards this to the GatewayServices Element which is respnnQihle for the connection estFffbliQh ~t. This respQnQihility 1nchlf;les Co~ g the connection to the originating node, keeping the state of the MPTN connection, and preparing the Relay for the connection. The Gateway Services Element forwards the resulting "connect request COI~il tion" BLU
to Manager. The Manager knows that the original inr ~ g connection request was a native request (Fig. 11a) so the Manager parses the MPTN Connect confirmation to get the needed information, lncluf~ing source and destination transport user fffff'~ fff~ 3f~f8~ L~Uiled quality of service, and a connect request U"Ull~
parameter. The Manager forwards this to Transport Provider 1 at 87, along with the C~ fn~g parameters. The Transport Provider adds the transport protocol-speff-~f~ff- header and trailer and transmits the native "connect request co~i. t- n BLU onto SPTN 1 at 88. At 89, the Gateway Services Element sends a -- ffffge, "Relay - ConnffPctinn EstAhliQhf~d~ to the Manager, for forwarding to the Relay, at 9'0, to fnfff~;ffr~ffte that the connfrfffctiff n has been esP-ff1-fffliQhf~f1f. At this point, the f ff~ffnnfrfffct fnn ig egt~fff~fffliQhfPffff~ and any BLUs received at Transport Provider 1 from this C~ f~ Wil] be forwarded directly to the Relay for forwarding to Transport Provider 2.
,. . ,. ".
No illustration is g~ven where there is a connection request from an MPTN
, ~ , .,'"''~','~,.'.
::
RA9-92-027X 20 2 1 ~ O ~ 1 2 Node as the method for processing this request is identical to the method described in conjunction with Figures lla and llb, except that there is additional proces~inF
required for the MPTN header which is received with the connection request BLU.
The proces~ing of the MPTN header is described in conjunction with Figure 10.
Thus, it can be seen that the MPTN Gateway of the present invention provides transparent interconnection of two or more SPTNs running different transport layer protocols. The primary function of the gateway is to connect individual SPTNs toform nn integrntrd hetorogeneous hLPTN orinternet~ork.
, '; ~
'~' . '1 . , ~ ' ' ' ' ,, ''',"'-',
1) from GW2 32 to ND6 25). If the destination node is an MPTN node (such as ND6 25 (Fig. 1)), routing from the last MPTN Gateway to the destination uses MPTN
Protocols. Where the destin~tion node is a native, or non-MPTN node, (such as ND7 26 (Fig. 1) ), routing from the last MPTN Gateway to the destination uses the native protocols of the transport provider.
In supporting non-MPTN nodes, the MPTN gateway must support transport pl~vide.~ that use both search based and routing-table based routing. With ~earch based transport providers, the route from the source to the destin~ti-ln is not known at the time the connection request is made (or datagram is sent). A search is conducted to find where the destination is located, and then the route to the dest;nsti~-n is calculated . Transport providers that use search based routing include protocols for searching for~the requested destination and calculating the best route once the destin~tir~n is found. ~r~mrlRs of search based transport providers include ~ ~ ,;,.,,- :
.- ........
NetBIOS and SNA.
With a routing table based protocol, the route to the destination is known before the connection request is made (or datagram sent) . When a connection request is made (or datagram sent), the routing table in the node points to the "next hop"
along the path in routing the request to the destination. Transport providers that use a routing table based protocol include routing protocols for building the "next hop" routing tables and for maintaining the routing tables. Examples of routing table based transport providers include OSI and TCP/IP. - ~
':' '' ' '-To support transport providers that use a search based protocol, the MPTNGateway must participate in the search and route calculation protoc~ls. This involves a number of changes, or deltas, to the transport provider. This is shown in Fig. 5 where a native search request is received by MPTN Gateway 30 from a native node on SPTN 1 at 100. At 101, Transport Provider 1 parses the transport protocol ~e~ :ric header and det.,, ~nP~ from the destination address field whether the search request must be forwarded to the MPTN network. If the search is to beforwarded, the transport provider will pass the search request across the GSPB to ~ -~
the Manager. At 10a, the Manager det~ that it is a search request, and f~.. rds the request to Gateway Services. At 103, Gateway Services forwards the ident~ ti~n of the des~:-.P~ n to the Routing Service Element. At 104, Routing Services ~' t returns the address of the "next hop" to Gateway Services Element.In order to dete. ~ - the address of the next hop, the Routing Services Element must perform a ~ of steps. This is shown in Fig. 5A. At 140, the Routing S_. ~lces Element lec~ivas the destinAt;nn address from the Gateway Services F1 t. At 141, the Routing Services Element dete. -- whether the destination can be reached by searching its routing tables for the NetId of the desffnAt;~ naddr~ss. If not, at 142, the Routing Services Element returns a negative response to the requesting native node. If so, at 143, the Routing Services ~l t dete. ~ -- whether the NetId of the destinAtion address is a split NetId (i.e., the ' ~;
- ,:, .
:
RA9-92-027X 13 2 1 3 0 ~ 1 2 , .~: ,~ ,. ..
network is split into two or more disjoint SPTNs and the destination could be in one --of several SPTNs). If not, at 144, the Routing Services Element r~ ,.s the next hop to the requesting native node. If it is a split NetId, at 145, the Routing Services Element determines whether there is a cache entry for the NetId of the destination address . If so, at 146 j the Routing Services Element returns the cached next hop value to the requesting native node. If not, at 147, the Routing Services Element initiates a search of each potential SPTN. This is described in copending Cana~lian application no. 2,105,040, filed August 27, 1993, entitled "Inter-Domain Multicast Routing". This procedure detailed in Fig. 5A is used whenever the Routing Services Element is requested by the Gateway Services Element for routing infol ti~n.
Referring again to Fig. 5, once it is detel ~ e~ that the destination can be reached through this MPTN Gateway, General Services Element responds to S
Tranaport Provider 1 with the ~o~ilive search response. This is shown by steps 104-106. At 107, Transport Provider 1 then responds to the original search/verifi- ~at;rn request, stating that the requested destination is located on this MPTN Gateway. The MPTN Gateway will subsequently receive a native connection request (or datagram). This is described below in conjunction with Figure 9.
Figures 6A and 6B illustrate the message flows when an MPTN search is ~eceived from another MPTN Gateway (MPTN GW2) . At 109, a c- nn~cti~n is alreadyesteh~ cl between the two MPTN Gateways and, at 110, Transport Provider 2 r~c~lv~,s a BLU (representing the MPTN search request) from MPTN GW2. At 111, ~;
Transport Provider 2 parses the header and trailer and forwards the MPTN data and cQnn~t;r~r ID to the Manager. Based upon the conn~ct;on ID, the Manager, at 112,fu... - ds the MPTN search request to the Routing Services Element. At 113, the Routing Services Element detel ~ ec that it is an MPTN search request and that the Des~ination NetId is in SPTN1 (to which MPTN GW1 is providing access). !Routing Services Element initiates a search request of SPTN1 at 113. At 114, the Gateway .. .. :
RA9-92-027X 14 ~
.".., ;, Services Element forwards the request to the Manager which, in turn, forwards the request to the Transport Provider 1, at 115. At 116, Transport Provider 1 initiates the native search protocol for the requested destination address.
As shown on Fig. 6B, at 117, Transport Provider 1 receives a positive ;
response to search from SPTN1. At 118, Transport Provider 1 parses the header/trailer and forwards the positive response to the Routing Services Element (via Manager, at 119, and Gateway Services Element, at 120) . The Routing Services Element, at 121, builds a positive response to the MPTN search and sends to the Manager which forwards the positive response to Transport Provider 2 at 122. At 123, Transport Provider 2 forwards the po~ilive response to the requesting MPTN --GW.
Where the MPTN search request needs to be forwarded to another MPTN
Gateway, Gateway Services Element will forward the MPTN search request and next hop Gateway address to Manager, which will forward the search request to the next MPTN Gateway.
To support transport providers that use a routing table based protocols, the MPTN Ga~eway must participate in the routing protocols that build and maintain the -transport provider loulil~g tables. This involves a number of changes, or deltas, to the transport provider. The method of building transport provider routing tables ;
is shown in Fig. 7 while the advertising of transport provider inf~. ti~ln is shown in Fig. 8. -In Fig. 7, at 130, Transport Provider 1 learns of native routing inf". -tion and forwards this i~lfo~ tion to the Manager. At 131, 132 and 133, Transport Provider 1, Manager and Gateway Services Element, respectively, forwards this -11~. t~nn to the Routing Services'~l t. At 134, the Routing Services Element ;
utilizes IDRP protocols to distribute this routing inf~l -tir.n to adjacent MPTN i , . .
:,-;",. ..,: ;.
" ,i~, "
, ~.,.,,.,:
~ ~,, ~,...
2~ 30~2 RA9-92-027X 15 - ~
, ~ , Gateways.
Fig. 8 illustrates the message flows when MPTN Gateway 30 receives routing i -information from an adjacent MPTN Gateway. In general, when the MPTN Gateway receives new routing information ( via the IDRP protocols ), Routing Services Element checks the protocol type of the new routing information to see if it is the same type as any of the SPTNs this Gateway supports. If they do match, the new routing information will be passed across the GSPB into any SPTN that has the same transport protocol type. This process of forwarding MPTN routing information into an SPTN is referred to as advertising. The transport provider then take~i this routing information and propAg~tes it through the SPTN using the native routing protocol of that transport provider. Subsequent native connect requests (or datagrams) whose destinot;nr routing information were advertised this way, will be routed to the MPTN Gateway. The transport provider will receive the connection ;
request (or datagram) and will pass it across GSPB. This is described in Figure 9.
Using the method des-rihed above the MPTN Gateway provides maximum po~ h1 com~e ilivily to native (non-MPTN) nodes that use routing-based ~rotocols.
j , The spe.~if~c message flows for Fig. 8 are as follows. At 135, the Routing Services Element learns the new routing info. tinn and d~t~ that it affects an Attr~ SPTN. The Routing Services Element adv~ ies that info. tinn into ; the ,~ect~,d SPTN. At 136 and 137, the Gateway Services Element and the Manager re~pe-tively forward this info~ tinn to Transport Provider 1. At 138, Transport Provider 1 uses native routing protocols to adv. . l;se the new routing info. tinn .
:''' :
:~ ;
21304~2 Figure 9 illustrates the operation of Gateway GW1 30 (Fig. 2) where a BLU in the form of a datagram, i.e., a connectionless data packet, is to be conveyed between a Native Node on SPTN 1 to a node (Node 2) on SPTN 2. The path from Node 1 to Node 2 traverses Gateway 30. Node 2 could, alternatively, be a gatewayfor interconnection to another SPTN (i.e., SPTN 3). In the figure, the arrows indicate the direction of the flow of messages and the corresponding Native NodeBLU (of the form shown in Figure 3) as it is processed. At 51, the particular Transport Provider receives the BLU from the Native Node on SPTN 1 (to be conveyed to Node 2 on SPTN 2), parses the transport protocol-specific header (and trailer, if any) and d~te~ ~ -9 from the destination addresc~ field that Node 2 is not located in SPTN 1 and needs to be forwarded to another SPTN. The Transport Provider forwards T User Payload to the Manager at 52 with parameters indicatingto the Manager the transport user destination and the source addresses, re~luiled quality of service, user characteristics, and indication that it is a datagram to be forwarded. The Manager forwards the parameters and the T User Payload to the Gateway Services Element at 53 in order to obtain routing information. Gateway Services Element forwards the identifi-~ti~.n of the destination user to the Routing Services Element at 54. Routing Services Element d~tel ~ ~s, from its look-up table (as illustrated in Fig. 5A ii~c~l~sed above), where the destin~tir.n user is located and l~tu~.~S~ at 55, to the Gateway Services Element the "next hop" thereby identifying the particular transport provider address to which the datagram needs to be forwarded, Transport Provider 2, in this eYP le. At 56, the Gateway Services r~ -- t builds an MPTN header to the T_User Payload and forwards the resulting MPTN datagram to the Manager. At 57, Manager forwards the new MPTN
datagram to Transport Provider 2 along with the co..~s~n~ling par to~s to in~ te to the Transport Provider the transport provider source and desffn~tinn add.ecaca of the "next hop", re~luiled quality of service, user characteristics, and in-~ ti-m that it is a datagram for forwarding. The Transport Provider adds the transport protocol-specific header and trailer and transmits the resulting BLU onto SPTN 2 at 58.
~',~, '.' ,~ ,.! '. , " , , . ! .
2130~5~2 Figure 10 illustrates the operation of Gateway 30 where a BLU in the form of a datagram is to be conveyed between an MPTN Node on SPTN 1 to an MPTN node on SPTN 2. The path from Node 1 to Node 2 traverses Gateway 30. At 61, the particular Transport Provider receives the BLU from the MPTN Node on SPTN 1, parses the transport protocol-specific header (and trailer, if any) and determines from the source and destination address fields that the datagram is addressed to the well-known MPTN port on Gateway 30. As is known in the industry, a well-known port is a local address that is reserved for a specific service. Only MPTN datagrams will be addres3ed to this well-known port, thus the Transport Provider knows to forward the MPTN datagram to the Manager. The Transport Provider forwards the MPTN dstagram (which includes the MPTN header and the T User Payload or user datagram), and pal _ tel s to the Manager at 62. From the transport user addresses in the MPTN header, the Manager detel ~ e~ that it is a MPTN datagram for forwarding to another SPTN and forwards the BLU to the Gateway Services Element for routing info. t;- n at 63. Gateway Services Element forwards the ident;fil ~t;on of the destinAt~n user to the Routing Services Element at 64. Routing Services Element determines, from its look-up table (as described in Fig. 5A and e~ nying text), where the destination user is located and returns, at 65, to the Gateway Services Element the "next hop" thereby id~nl~yillg the particular l. .ns~u l provider add-2ss to which the MPTN datagram needs to be forwarded. At66, the Gateway Services Element forwards the MPTN datagram back to the Manager.Manager forwards the MPTN datagram to Transport Provider 2 at 67, along with theCC~.2 3~ ~ing ~Ll tG~S to indicate to the Transport Provider the source and dest;natinr~ transport provider add~e~ses of the next hop and re~ l.e~l quality of service. The Transport Provider adds the transport protocol-specific header and trailer and transmits the BLU onto SPTN 2 at 68.
.; ' -:, Figures lla and llb illustrate the operation of Gateway 30 where a "connect"
le4ue~l BLU is received frdm a Native Node on SPTN 1 requésting to be connected ~ ~ -to an MPTN Node on SPTN 2. The path from Node 1 to Node 2 traverses Gateway 30. ~ ~ -~.,,~,' .' . ". ,,:, RA9-92-027X 18 21~0412 In Figure lla, at 71, the particular Transport Provider receives the BLU from the Native Node on SPTN 1, parses the transport protocol-specific header (and trailer, if any), recop~ni7e~ from the "C,: nd Type" field that it is a "connect request"from the Native Node and determines from the destination address field that the connect request needs to be forwarded to an MPTN Gateway. The Transport Provider forwards the r~ ining portion of the BLU which includes the T User Payload to the Manager at 72 along with parameters giving the source and destination user addresses, required quality of service transport characteristics and a "connect request" parameter. The Manager forwards the parameters to the Gateway Services Element to obtain routing information and to establish the connection to Node 2 at 73.
Gateway Services ~1 t forwards the identification of the destiniati-.n user to the Routing Services Element at 74 . Routing Services Element determines, from its look-up table (Fig. 5A and ~c~ -nying text) and, when necessary, initiates a search of the MPTN network, where the destination user is located and relu~.ls, at 75, to the Gateway Services Element the "next hop" thereby identifying the particular transport provider address to which the "connect request" needs to be forwarded.At 76, the Gateway Services Element builds an MPTN Connect which in~lt~ s the T User ~yload and forwards the resulting "connect request" to the Manager.
Manager forwards the connect request to the Transport Provider 2 at 77, along with the cu..c ~-n~linf~ pal tels to indicate to the Transport Provider the source and dest~nAt~r~n transport provider addresses of the next hop, ra~lui~;d quality of service, and MPTN Connect. The Transport Provider estAhli~ih~s a connection withthe MPTN node on SPTN 2 and sends the MPTN Connect (with transport specific header and trailer) as the first data packet on the connection at 78. At 79, theGateway Services Element sends a message, "Relay Get Ready", to the Manager, forforwarding to the Relay, at 80, to prepare for a connection.
In order for a connection to be estA1)1i~h~, an "end-to-end" confirmation must be estAhli~h~cl so that each "hop" along the connection path is available for estAh1iching the connection. In other words, the "connect request" BLU is - ': ~.;'~
:: ~ .'':
' ,:"''~,," ' ,: ., , . , ., ", , " ,, ~ ~ :
2130~12 ;
forwarded throughout the MPTN to all of the intermediary nodes so that each is prepared for the connection. It is not until a "connect request confirmation" isreceived by the orifinating node that the MPTN connection i8 conQi~fff~fred to be established .
As shown in Figure 11b, at 81, the "MPTN Connect request confirmation" i8 received at Transport Provider 2 from Node 2 on SPTN 2. This "MPTN Connect request COl~il tion" inf~if~f~tes to the Gateway that the connection path i8 ready for user data e~cf hf~nEe. As with all BLUs, the transport-specific header and trailer are parsed, and the ~ fffr MPTN Connect confirmation(with pa, teLf3ff) is forwarded to the Manager for procaQ~ g. The Manager forwards this to the GatewayServices Element which is respnnQihle for the connection estFffbliQh ~t. This respQnQihility 1nchlf;les Co~ g the connection to the originating node, keeping the state of the MPTN connection, and preparing the Relay for the connection. The Gateway Services Element forwards the resulting "connect request COI~il tion" BLU
to Manager. The Manager knows that the original inr ~ g connection request was a native request (Fig. 11a) so the Manager parses the MPTN Connect confirmation to get the needed information, lncluf~ing source and destination transport user fffff'~ fff~ 3f~f8~ L~Uiled quality of service, and a connect request U"Ull~
parameter. The Manager forwards this to Transport Provider 1 at 87, along with the C~ fn~g parameters. The Transport Provider adds the transport protocol-speff-~f~ff- header and trailer and transmits the native "connect request co~i. t- n BLU onto SPTN 1 at 88. At 89, the Gateway Services Element sends a -- ffffge, "Relay - ConnffPctinn EstAhliQhf~d~ to the Manager, for forwarding to the Relay, at 9'0, to fnfff~;ffr~ffte that the connfrfffctiff n has been esP-ff1-fffliQhf~f1f. At this point, the f ff~ffnnfrfffct fnn ig egt~fff~fffliQhfPffff~ and any BLUs received at Transport Provider 1 from this C~ f~ Wil] be forwarded directly to the Relay for forwarding to Transport Provider 2.
,. . ,. ".
No illustration is g~ven where there is a connection request from an MPTN
, ~ , .,'"''~','~,.'.
::
RA9-92-027X 20 2 1 ~ O ~ 1 2 Node as the method for processing this request is identical to the method described in conjunction with Figures lla and llb, except that there is additional proces~inF
required for the MPTN header which is received with the connection request BLU.
The proces~ing of the MPTN header is described in conjunction with Figure 10.
Thus, it can be seen that the MPTN Gateway of the present invention provides transparent interconnection of two or more SPTNs running different transport layer protocols. The primary function of the gateway is to connect individual SPTNs toform nn integrntrd hetorogeneous hLPTN orinternet~ork.
, '; ~
'~' . '1 . , ~ ' ' ' ' ,, ''',"'-',
Claims (27)
1. A gateway for being interconnected between a first single protocol transport network (SPTN) running a first transport provider protocol and a second SPTN
running a second transport provider protocol, for receiving from a node connected to said first SPTN a basic link unit (BLU) having header information conforming to said first protocol, for processing said first protocol BLU to a BLU having header information conforming to said second protocol, and conveying said second protocol BLU to a node connected to said second SPTN, said gateway comprising:
a first SPTN transport provider having means for receiving said first protocol BLU and means for processing said first protocol header information into a general form;
a second SPTN transport provider having means for conveying said second protocol BLU to said second SPTN, and means for processing general form header information into header information conforming to said second protocol; and an element for providing general gateway services for said first and second SPTN transport providers comprising means for receiving general form header information from said first SPTN transport provider, means for processing said received general form header information, means for cresting new general form header information and means for building a multiprotocol transport network (MPTN) header and means for conveying to said second SPTN transport provider said new general form header information and said MPTN header.
running a second transport provider protocol, for receiving from a node connected to said first SPTN a basic link unit (BLU) having header information conforming to said first protocol, for processing said first protocol BLU to a BLU having header information conforming to said second protocol, and conveying said second protocol BLU to a node connected to said second SPTN, said gateway comprising:
a first SPTN transport provider having means for receiving said first protocol BLU and means for processing said first protocol header information into a general form;
a second SPTN transport provider having means for conveying said second protocol BLU to said second SPTN, and means for processing general form header information into header information conforming to said second protocol; and an element for providing general gateway services for said first and second SPTN transport providers comprising means for receiving general form header information from said first SPTN transport provider, means for processing said received general form header information, means for cresting new general form header information and means for building a multiprotocol transport network (MPTN) header and means for conveying to said second SPTN transport provider said new general form header information and said MPTN header.
2. The gateway defined in Claim 1 wherein said first protocol BLU further has an MPTN header and said general gateway services element further comprises meansfor receiving said MPTN header from said first SPTN transport provider, means for processing said MPTN header, and means for creating new general form header information based upon said received MPTN header and means for conveying said new general form header information and said MPTN header to said second SPTN
transport provider.
transport provider.
3. The gateway defined in Claim 2 wherein said MPTN header processing means comprises a routing services element for determining the address of said node on said second SPTN based upon said received MPTN header information.
4. The gateway defined in Claim 2 wherein said first SPTN transport provider further has a well-known port for determining whether said first protocol BLU is an MPTN BLU.
5. The gateway defined in Claim 1 wherein said first SPTN transport provider further comprises means for conveying said first protocol BLU to said first SPTN and said first protocol header information processing means comprises means for determining whether said first protocol BLU needs to be conveyed to another SPTNor needs to be conveyed to said first SPTN.
6. The gateway defined in Claim 1 wherein said general gateway services element further comprises a routing services element for determining the address of said node on said second SPTN based upon said received general form header information.
7. The gateway defined in Claim 1 further comprising, in addition to said first SPTN transport provider and said second SPTN transport provider, a plurality of unique SPTN transport providers, different from said first SPTN transport provider, from said second SPTN transport provider and from each other, each forproviding an transport provider to an SPTN running a correspondingly unique transport protocol, each unique SPTN transport provider having means for receiving a BLU having header information conforming to said corresponding unique SPTN
protocol, means for processing said unique SPTN protocol header information intogeneral form header information, means for receiving from said general gateway services element and processing general form header information into unique protocol header information and means for conveying a unique protocol BLU to said unique SPTN.
protocol, means for processing said unique SPTN protocol header information intogeneral form header information, means for receiving from said general gateway services element and processing general form header information into unique protocol header information and means for conveying a unique protocol BLU to said unique SPTN.
8. The gateway defined in Claim 1 wherein said general gateway services element further comprises a gateway services element for relaying datagrams fromsaid first SPTN transport provider to said second SPTN transport provider.
9. The gateway defined in Claim 8 wherein said gateway further comprises a relay and said gateway services element establishes connections between said first and second SPTN transport providers utilizing said relay.
10. In a gateway for being interconnected between a first SPTN running a first transport provider protocol and a second SPTN running a second protocol, said gateway comprising first and second transport providers for interfacing with said first and second SPTNs and further comprising a general gateway services elementfor providing gateway services to said first and second transport providers, a method of conveying a basic link unit (BLU) from said first SPTN to said second SPTN, said received BLU consisting of header information conforming to said first protocol, said method comprising the steps of:
receiving said BLU from said first SPTN in said first transport provider;
in said first transport provider, processing said header information into a general form understood by said general gateway services element;
conveying to said general gateway services element said general form header information;
in said general gateway services element, building a multiprotocol transport network (MPTN) header;
in said general gateway services element, creating new general form header information based upon said general form header information;
conveying to said second transport provider said MPTN header and said new general form header information; and in said second transport provider, processing said new general form header information into a header information conforming to said second protocol; and from said second transport provider, conveying, to said second SPTN, a second protocol BLU having said second protocol header information and said MPTNheader
receiving said BLU from said first SPTN in said first transport provider;
in said first transport provider, processing said header information into a general form understood by said general gateway services element;
conveying to said general gateway services element said general form header information;
in said general gateway services element, building a multiprotocol transport network (MPTN) header;
in said general gateway services element, creating new general form header information based upon said general form header information;
conveying to said second transport provider said MPTN header and said new general form header information; and in said second transport provider, processing said new general form header information into a header information conforming to said second protocol; and from said second transport provider, conveying, to said second SPTN, a second protocol BLU having said second protocol header information and said MPTNheader
11. The method defined in Claim 10 further comprising, before said MPTN
header building step, the step of examining said general form destination address and determining an intermediary address and further wherein, in said building step, said MPTN header is based upon said intermediary address.
header building step, the step of examining said general form destination address and determining an intermediary address and further wherein, in said building step, said MPTN header is based upon said intermediary address.
12. The method defined in Claim 11 wherein said BLU received by said first transport provider further consists of an MPTN header of a form understood by said general gateway services element and said building step comprises the steps of examining said received MPTN header, determining an intermediary address based upon said MPTN header, and creating said new general form header information based upon said intermediary address.
13. The method defined in Claim 10 wherein said gateway further comprises a relay for establishing a connection through said gateway between said first SPTN
and said second SPTN and said received BLU further has a command field conforming to said first protocol, said method further comprising the step, after said destination address processing step, of processing said command field into a general form understood by said general services element, and, before said building step, thestep of examining said general form command field and, where said command is a CONNECT command, said building step comprises building an MPTN header having an MPTN CONNECT command.
and said second SPTN and said received BLU further has a command field conforming to said first protocol, said method further comprising the step, after said destination address processing step, of processing said command field into a general form understood by said general services element, and, before said building step, thestep of examining said general form command field and, where said command is a CONNECT command, said building step comprises building an MPTN header having an MPTN CONNECT command.
14. The method defined in Claim 10 wherein said MPTN header building step comprises the step determining the address of said node on said second SPTN based upon said MPTN header information.
15. A gateway for being interconnected between a first single protocol transport network (SPTN) running a first transport provider protocol and a second SPTN running a second transport provider protocol, for receiving from a multiprotocol transport (MPTN) node connected to said first SPTN a basic link unit (BLU) having header information conforming to said first protocol and further having MPTN header information, for processing said first protocol BLU to a BLU
having header information conforming to said second protocol, and conveying saidsecond protocol BLU to a native node connected to said second SPTN, said gatewaycomprising:
a first SPTN transport provider having means for receiving said first protocol BLU and means for processing said first protocol header information into a general form;
a second SPTN transport provider having means for conveying said second protocol BLU to said second SPTN, and means for processing general form header information into header information conforming to said second protocol; and an element for providing general gateway services for said first and second SPTN transport providers comprising means for receiving general form header information and said MPTN header information from said first SPTN transport provider, means for processing said received general form header information andsaid MPTN header information, means for creating new general form header information and means for conveying to said second SPTN transport provider said new general form header information.
having header information conforming to said second protocol, and conveying saidsecond protocol BLU to a native node connected to said second SPTN, said gatewaycomprising:
a first SPTN transport provider having means for receiving said first protocol BLU and means for processing said first protocol header information into a general form;
a second SPTN transport provider having means for conveying said second protocol BLU to said second SPTN, and means for processing general form header information into header information conforming to said second protocol; and an element for providing general gateway services for said first and second SPTN transport providers comprising means for receiving general form header information and said MPTN header information from said first SPTN transport provider, means for processing said received general form header information andsaid MPTN header information, means for creating new general form header information and means for conveying to said second SPTN transport provider said new general form header information.
16. The gateway defined in Claim 15 wherein said general gateway services element further comprises means for conveying to said second SPTN transport provider said MPTN header information.
17. The gateway defined in Claim 15 wherein said MPTN header information processing means comprises a routing services element for determining the address of said node on said second SPTN based upon said received MPTN header information.
18. The gateway defined in Claim 15 wherein said first SPTN transport provider further has a well-known port for determining whether said first protocol BLU is an MPTN BLU.
19. The gateway defined in Claim 15 wherein said first SPTN transport provider further comprises means for conveying said first protocol BLU to said first SPTN and said first protocol header information processing means comprises meansfor determining whether said first protocol BLU needs to be conveyed to another SPTN or needs to be conveyed to said first SPTN.
20. The gateway defined in Claim 15 wherein said general gateway services element further comprises a routing services element for determining the address of said node on said second SPTN based upon said received general form header information.
21. The gateway defined in Claim 15 further comprising, in addition to said first SPTN transport provider and said second SPTN transport provider, a plurality of unique SPTN transport providers, different from said first SPTN transport provider, from said second SPTN transport provider and from each other, each forproviding an transport provider to an SPTN running a corresponding unique transport protocol, each unique SPTN transport provider having means for receiving a BLU having header information conforming to said corresponding unique SPTN
protocol, means for processing said unique SPTN protocol header information intogeneral form header information, means for receiving from said general gateway services element and processing general form header information into unique protocol header information and means for conveying a unique protocol BLU to said unique SPTN.
protocol, means for processing said unique SPTN protocol header information intogeneral form header information, means for receiving from said general gateway services element and processing general form header information into unique protocol header information and means for conveying a unique protocol BLU to said unique SPTN.
22. The gateway defined in Claim 15 wherein said general gateway services element further comprises a gateway services element for relaying datagrams fromsaid first SPTN transport provider to said second SPTN transport provider.
23. The gateway defined in Claim 22 wherein said gateway further comprises a relay and said gateway services element establishes connections between said first and second SPTN transport providers utilizing said relay.
24. In a gateway for being interconnected between a first single protocol transport network (SPTN) running a first transport provider protocol and a second SPTN running a second protocol, said gateway comprising first and second transport providers for interfacing with said first and second SPTNs and further comprising a general gateway services element for providing gateway services to said first and second transport providers, a method of conveying a basic link unit (BLU) from said first SPTN to said second SPTN, said received BLU consisting of header information conforming to said first protocol and further consisting of multiprotocol transport network (MPTN) header information, said method comprising the steps of:
receiving said BLU from said first SPTN in said first transport provider;
in said first transport provider, processing said header information into a general form understood by said general gateway services element;
conveying to said general gateway services element said general form header information and said MPTN header information;
in said general gateway services element, processing said MPTN header information;
in said general gateway services element, creating new general form header information based upon said general form header information;
conveying to said second transport provider said new general form header information; and in said second transport provider, processing said new general form header information into a header information conforming to said second protocol; and from said second transport provider, conveying, to said second SPTN, a second protocol BLU having said second protocol header information.
receiving said BLU from said first SPTN in said first transport provider;
in said first transport provider, processing said header information into a general form understood by said general gateway services element;
conveying to said general gateway services element said general form header information and said MPTN header information;
in said general gateway services element, processing said MPTN header information;
in said general gateway services element, creating new general form header information based upon said general form header information;
conveying to said second transport provider said new general form header information; and in said second transport provider, processing said new general form header information into a header information conforming to said second protocol; and from said second transport provider, conveying, to said second SPTN, a second protocol BLU having said second protocol header information.
25. The method defined in Claim 24 wherein said MPTN header information processing step comprises the steps of examining said received MPTN header, determining an intermediary address based upon said MPTN header, and creating said new general form header information based upon said intermediary address.
26. The method defined in Claim 24 wherein said gateway further comprises a relay for establishing a connection through said gateway between said first SPTN
and said second SPTN and said MPTN header information further has an MPTN
command field, said MPTN header information processing step further comprising the step of examining said MPTN command field and, where said command is an MPTN
CONNECT command said method further comprising the step of building a general form command field having a general form CONNECT command.
and said second SPTN and said MPTN header information further has an MPTN
command field, said MPTN header information processing step further comprising the step of examining said MPTN command field and, where said command is an MPTN
CONNECT command said method further comprising the step of building a general form command field having a general form CONNECT command.
27. The method defined in Claim 24 wherein said MPTN header processing step comprises the step determining the address of said node on said second SPTN based upon said MPTN header information.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US17598593A | 1993-12-30 | 1993-12-30 | |
| US175,985 | 1993-12-30 | ||
| US1789,816 | 1994-02-01 | ||
| US08/189,816 US5491693A (en) | 1993-12-30 | 1994-02-01 | General transport layer gateway for heterogeneous networks |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2130412A1 CA2130412A1 (en) | 1995-07-01 |
| CA2130412C true CA2130412C (en) | 1998-01-20 |
Family
ID=26871751
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002130412A Expired - Fee Related CA2130412C (en) | 1993-12-30 | 1994-08-18 | General transport layer gateway for heterogeneous networks |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5491693A (en) |
| EP (1) | EP0666670A2 (en) |
| JP (1) | JP2571679B2 (en) |
| CA (1) | CA2130412C (en) |
Families Citing this family (92)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2132363A1 (en) * | 1994-09-19 | 1996-03-20 | Norman Wong | Integrated management of multiple networks of different technologies through hierarchical pass-through routing and multi-network service management |
| US5761425A (en) * | 1994-12-02 | 1998-06-02 | Compuserve Incorporated | System for facilitating data transfers between host computers and workstations by having a first, second and third computer programs communicate in a matching application-level protocol |
| US5659684A (en) * | 1995-02-03 | 1997-08-19 | Isdn Systems Corporation | Methods and apparatus for interconnecting personal computers (PCs) and local area networks (LANs) using packet protocols transmitted over a digital data service (DDS) |
| US5600644A (en) * | 1995-03-10 | 1997-02-04 | At&T | Method and apparatus for interconnecting LANs |
| US5822324A (en) * | 1995-03-16 | 1998-10-13 | Bell Atlantic Network Services, Inc. | Simulcasting digital video programs for broadcast and interactive services |
| US5651010A (en) * | 1995-03-16 | 1997-07-22 | Bell Atlantic Network Services, Inc. | Simultaneous overlapping broadcasting of digital programs |
| US5673263A (en) * | 1995-03-31 | 1997-09-30 | International Business Machines Corporation | Method for using an IP address-based routing protocol in an ATM environment |
| US5742762A (en) * | 1995-05-19 | 1998-04-21 | Telogy Networks, Inc. | Network management gateway |
| US5710908A (en) * | 1995-06-27 | 1998-01-20 | Canon Kabushiki Kaisha | Adaptive network protocol independent interface |
| US5613071A (en) * | 1995-07-14 | 1997-03-18 | Intel Corporation | Method and apparatus for providing remote memory access in a distributed memory multiprocessor system |
| US5802053A (en) * | 1995-10-13 | 1998-09-01 | International Business Machines Corporation | Transport gateway between a native network and a mixed network |
| JP2891146B2 (en) * | 1995-10-23 | 1999-05-17 | 日本電気株式会社 | Network server |
| FI102860B (en) * | 1995-11-07 | 1999-02-26 | Nokia Telecommunications Oy | Procedure and apparatus for transmitting an electronic payment |
| US5809233A (en) * | 1995-12-05 | 1998-09-15 | Lucent Technologies Inc. | Method of mapping from ATMARP to NHRP |
| US5790548A (en) | 1996-04-18 | 1998-08-04 | Bell Atlantic Network Services, Inc. | Universal access multimedia data network |
| US6308148B1 (en) * | 1996-05-28 | 2001-10-23 | Cisco Technology, Inc. | Network flow data export |
| US6243667B1 (en) * | 1996-05-28 | 2001-06-05 | Cisco Systems, Inc. | Network flow switching and flow data export |
| JP2845207B2 (en) * | 1996-08-15 | 1999-01-13 | 日本電気株式会社 | Address resolution device |
| US6229809B1 (en) | 1996-10-11 | 2001-05-08 | Novell, Inc. | Method and system for combining computer network protocols |
| US7383341B1 (en) * | 1996-10-15 | 2008-06-03 | Kabushiki Kaisha Toshiba | Data transfer control device, relay device and control device suitable for home network environment |
| US6366958B1 (en) * | 1996-10-21 | 2002-04-02 | International Business Machines Corporation | NETBIOS protocol support for a DCE RPC mechanism |
| US6016307A (en) | 1996-10-31 | 2000-01-18 | Connect One, Inc. | Multi-protocol telecommunications routing optimization |
| US6473404B1 (en) * | 1998-11-24 | 2002-10-29 | Connect One, Inc. | Multi-protocol telecommunications routing optimization |
| WO1998020647A1 (en) * | 1996-11-08 | 1998-05-14 | Integrated Telecom Technology | Method and apparatus to translate data streams among multiple parties |
| US6049832A (en) * | 1996-11-15 | 2000-04-11 | Wall Data Incorporated | Method for accessing information on a host computer from a client computer through an intelligent virtual host component |
| US6278532B1 (en) * | 1996-12-20 | 2001-08-21 | Link2It | Apparatus and method for reception and transmission of information using different protocols |
| US6011803A (en) * | 1997-01-13 | 2000-01-04 | Lucent Technologies Inc. | Distributed-protocol server |
| FR2758925B1 (en) * | 1997-01-28 | 1999-04-23 | Sextant Avionique | METHOD AND DEVICE FOR GENERALLY ROUTING MESSAGES TRANSMITTED IN FORMATS AND ACCORDING TO DIFFERENT PROTOCOLS |
| US6273622B1 (en) | 1997-04-15 | 2001-08-14 | Flash Networks, Ltd. | Data communication protocol for maximizing the performance of IP communication links |
| US6072806A (en) * | 1997-05-02 | 2000-06-06 | Aspect Telecommunications Corporation | Message-based communication system |
| US6266701B1 (en) * | 1997-07-02 | 2001-07-24 | Sitara Networks, Inc. | Apparatus and method for improving throughput on a data network |
| US6345315B1 (en) | 1997-08-13 | 2002-02-05 | Sudhindra N. Mishra | Method for platform and protocol independent communication between client-server pairs |
| WO1999009725A1 (en) | 1997-08-21 | 1999-02-25 | At & T Corp. | Packet redirection and message stream management |
| US6084859A (en) * | 1997-08-29 | 2000-07-04 | International Business Machines Corporation | Internet protocol assists using multi-path channel protocol |
| US6009467A (en) * | 1997-08-29 | 1999-12-28 | International Business Machines Corporation | System for checking status of supported functions of communication platforms at preselected intervals in order to allow hosts to obtain updated list of all supported functions |
| US6023734A (en) * | 1997-08-29 | 2000-02-08 | International Business Corporation | Establishing direct communications between two hosts without using a high performance LAN connection |
| US6003080A (en) * | 1997-08-29 | 1999-12-14 | International Business Machines Corporation | Internet protocol assists using multi-path channel protocol |
| US6006261A (en) * | 1997-08-29 | 1999-12-21 | International Business Machines Corporation | Internet protocol assists using multi-path channel protocol |
| US6003088A (en) * | 1997-08-29 | 1999-12-14 | International Business Machines Corporation | Blocking IP datagrams in a multi-path channel point-to-point environment |
| US5987515A (en) * | 1997-08-29 | 1999-11-16 | International Business Machines Corporation | Internet protocol assists using multi-path channel protocol |
| US5999974A (en) * | 1997-08-29 | 1999-12-07 | International Business Machines Corporation | Internet protocol assists for high performance LAN connections |
| US6078964A (en) * | 1997-08-29 | 2000-06-20 | International Business Machines Corporation | Establishing direct communications between two hosts without using a high performance LAN connection |
| US6185218B1 (en) * | 1997-08-29 | 2001-02-06 | International Business Machines Corporation | Communication method and apparatus for use in a computing network environment having high performance LAN connections |
| US6014699A (en) * | 1997-08-29 | 2000-01-11 | International Business Machines Corporation | Internet protocol assists for high performance LAN connections |
| US5974049A (en) * | 1997-08-29 | 1999-10-26 | International Business Machines Corporation | Internet protocol assists for high performance LAN connections |
| US6370592B1 (en) * | 1997-11-04 | 2002-04-09 | Hewlett-Packard Company | Network interface device which allows peripherals to utilize network transport services |
| IES981034A2 (en) * | 1997-12-09 | 1999-08-11 | Scp Powersoft Ltd | An inter-computer communications apparatus |
| KR100269146B1 (en) * | 1997-12-29 | 2000-10-16 | 윤종용 | Gateway device in atm-based access network |
| GB2333671A (en) * | 1998-01-23 | 1999-07-28 | Ibm | Multi-protocol communication |
| US6330617B1 (en) | 1998-02-27 | 2001-12-11 | Sabre Inc | System, method and computer program product for data conversion in a computer network |
| US6976080B1 (en) * | 1998-03-27 | 2005-12-13 | Hewlett-Packard Development Company, L.P. | Multiple-protocol communication subsystem controller |
| US6353620B1 (en) * | 1998-04-09 | 2002-03-05 | Ericsson Inc. | System and method for facilitating inter-nodal protocol agreement in a telecommunications |
| US6370121B1 (en) | 1998-06-29 | 2002-04-09 | Cisco Technology, Inc. | Method and system for shortcut trunking of LAN bridges |
| US6233619B1 (en) * | 1998-07-31 | 2001-05-15 | Unisys Corporation | Virtual transport layer interface and messaging subsystem for high-speed communications between heterogeneous computer systems |
| US6600743B1 (en) | 1998-08-25 | 2003-07-29 | International Business Machines Corporation | IP multicast interface |
| US6490285B2 (en) | 1998-08-25 | 2002-12-03 | International Business Machines Corporation | IP multicast interface |
| US6327621B1 (en) | 1998-08-25 | 2001-12-04 | International Business Machines Corporation | Method for shared multicast interface in a multi-partition environment |
| US6256322B1 (en) | 1998-10-02 | 2001-07-03 | Canon Kabushiki Kaisha | Bundling multiple network management packets |
| US6430164B1 (en) | 1999-06-17 | 2002-08-06 | Cellport Systems, Inc. | Communications involving disparate protocol network/bus and device subsystems |
| JP3816390B2 (en) * | 1999-07-02 | 2006-08-30 | 富士通株式会社 | Service allocation device |
| GB2356521A (en) * | 1999-07-20 | 2001-05-23 | Yat Sing Philip Poon | Multimedia network has protocol conversion |
| US7729986B1 (en) * | 1999-07-30 | 2010-06-01 | Visa International Service Association | Smart card transactions using wireless telecommunications network |
| SE517492C2 (en) * | 1999-10-18 | 2002-06-11 | Ericsson Telefon Ab L M | Method and apparatus for connecting a connection in a telecommunications system |
| US7508753B2 (en) * | 2000-01-31 | 2009-03-24 | At&T Intellectual Property, Ii, L.P. | Packet redirection and message stream management |
| US7197546B1 (en) * | 2000-03-07 | 2007-03-27 | Lucent Technologies Inc. | Inter-domain network management system for multi-layer networks |
| US6407341B1 (en) | 2000-04-25 | 2002-06-18 | International Business Machines Corporation | Conductive substructures of a multilayered laminate |
| DE10028715B4 (en) | 2000-06-08 | 2005-08-11 | Siemens Ag | Method for communication between communication networks |
| US6654373B1 (en) * | 2000-06-12 | 2003-11-25 | Netrake Corporation | Content aware network apparatus |
| WO2002015515A2 (en) * | 2000-08-11 | 2002-02-21 | Manugistics, Inc. | System and method for integrating disparate networks for use in electronic communication and commerce |
| US6912390B2 (en) * | 2000-12-22 | 2005-06-28 | Telefonaktiebolaget Lm Ericsson | Connection handling in SRNC relocation |
| US7016369B2 (en) * | 2000-12-22 | 2006-03-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Binding information for telecommunications network |
| GB2371726B (en) * | 2001-01-27 | 2005-08-17 | Mitel Corp | Transport protocols for application platforms over network portals |
| CN1174585C (en) | 2001-03-29 | 2004-11-03 | 三菱电机株式会社 | Inter-system connection adapter and terminal |
| US6606322B2 (en) * | 2001-08-17 | 2003-08-12 | Mcdata Corporation | Route lookup caching for a fiber channel switch |
| US20030093799A1 (en) * | 2001-11-14 | 2003-05-15 | Kauffman Marc W. | Streamed content Delivery |
| EP1457007B1 (en) * | 2001-12-21 | 2013-02-13 | Hewlett-Packard Development Company, L.P. | System for supply chain management of virtual private network services |
| US7870275B1 (en) * | 2002-02-28 | 2011-01-11 | Globalfoundries Inc. | Communication scheme-independent infrastructure |
| JP2004172932A (en) * | 2002-11-20 | 2004-06-17 | Hitachi Ltd | Data distribution system |
| KR20040110210A (en) * | 2003-06-18 | 2004-12-31 | 삼성전자주식회사 | Network Element System For supporting Independent Multi-Protocol service |
| US7508814B1 (en) | 2003-12-30 | 2009-03-24 | At&T Intellectual Property, Ii, L.P. | Electronic loop provisioning methods and systems |
| US7447788B2 (en) * | 2004-01-27 | 2008-11-04 | Dell Products L.P. | Providing host information to devices in multi SCSI transport protocols |
| EP1735672A1 (en) * | 2004-04-01 | 2006-12-27 | Delphi Technologies, Inc. | Method and protocol for diagnostics of arbitrarily complex networks of devices |
| US7519719B2 (en) * | 2004-04-15 | 2009-04-14 | Agilent Technologies, Inc. | Automatic creation of protocol dependent control path for instrument application |
| DE102004036488A1 (en) * | 2004-07-28 | 2006-03-23 | Siemens Ag | Method, apparatus and system for the adaptive optimization of transport protocols in the transmission of images |
| US7715429B2 (en) | 2004-12-06 | 2010-05-11 | Hewlett-Packard Development Company, L.P. | Interconnect system for supply chain management of virtual private network services |
| US9497109B2 (en) * | 2005-02-11 | 2016-11-15 | Hewlett Packard Enterprise Development Lp | Switching mesh with user-configurable paths |
| AT9173U1 (en) | 2005-12-06 | 2007-05-15 | Plansee Se | FIRST WALL COMPONENT WITH RINGSEGMENT |
| US7913529B2 (en) * | 2007-08-28 | 2011-03-29 | Cisco Technology, Inc. | Centralized TCP termination with multi-service chaining |
| US9825863B2 (en) * | 2008-02-27 | 2017-11-21 | Nokia Technologies Oy | Buffer control for multi-transport architectures |
| ATE541397T1 (en) * | 2008-02-27 | 2012-01-15 | Nokia Corp | TRANSPORT INDEPENDENT ARCHITECTURE |
| CN105515998B (en) * | 2015-11-26 | 2019-05-17 | 北京邮电大学 | A kind of method and system in the domain SPTN three layers of domain and two layers of domain intercommunication |
| CN110365549B (en) * | 2019-06-10 | 2021-09-24 | 烽火通信科技股份有限公司 | Processing method and processing system of SPTN (shortest Path bridging) network |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5243595A (en) * | 1990-01-30 | 1993-09-07 | Johnson Service Company | Combined connectionless and connection-oriented network control system |
| US5309437A (en) * | 1990-06-29 | 1994-05-03 | Digital Equipment Corporation | Bridge-like internet protocol router |
| US5251205A (en) * | 1990-09-04 | 1993-10-05 | Digital Equipment Corporation | Multiple protocol routing |
| US5235592A (en) * | 1991-08-13 | 1993-08-10 | International Business Machines Corporation | Dynamic switch protocols on a shared medium network |
-
1994
- 1994-02-01 US US08/189,816 patent/US5491693A/en not_active Expired - Fee Related
- 1994-08-18 CA CA002130412A patent/CA2130412C/en not_active Expired - Fee Related
- 1994-12-20 EP EP94480174A patent/EP0666670A2/en not_active Withdrawn
- 1994-12-21 JP JP6318394A patent/JP2571679B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2571679B2 (en) | 1997-01-16 |
| CA2130412A1 (en) | 1995-07-01 |
| EP0666670A2 (en) | 1995-08-09 |
| JPH07212405A (en) | 1995-08-11 |
| US5491693A (en) | 1996-02-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2130412C (en) | General transport layer gateway for heterogeneous networks | |
| US7386605B2 (en) | Methods and apparatus for automated edge device configuration in a heterogeneous network | |
| US6101549A (en) | Proxy-based reservation of network resources | |
| AU674300B2 (en) | System of extending network resources to remote networks | |
| US7009983B2 (en) | Methods and apparatus for broadcast domain interworking | |
| US20080151907A1 (en) | Ethernet/TMPLS Hybrid Network Operation Administration and Maintenance Frame Creation Method | |
| EP1100232A2 (en) | System, device, and method for allocating virtual circuits in a communication network | |
| US20050165961A1 (en) | Interworking functionality | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet | |
| Cisco | Configuring DECnet |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |