Patent Grant
7395343
1. Field
This invention relates generally to tunneling methods and apparatus for transporting messages across a network interface. More particularly, it concerns an extensible application programming interface that provides access and control mechanisms for use in encapsulating any existing data-, control-, or routing-related protocol within a generic transport protocol.
2. Background
A method is needed for transporting Signaling System 7 (SS7) messages across a Unix domain protocol/internet protocol (UDP/IP) interface. The method should accommodate other “application control” messages. To this end, a new protocol is needed that can wrap any type of “existing” protocol into a packet and deliver the encapsulated packet across the interface.
Method and apparatus for tunneling an existing protocol through a generic Internet protocol (IP) transport are described. The invented method includes providing a generic messaging structure that includes at least a transport protocol, a message buffer, a source-address field and one or more data fields for transparent routing of a user protocol over the IP transport and also providing an application program interface to the generic messaging structure, the interface including a mechanism for a user to choose a desired transport and associated protocol for transparently routing the user protocol over the transport in accordance with the chosen transport protocol within the one or more data fields. Alternatively or additionally, the invented method includes creating a base class library including plural defined source and header files and further providing a mechanism for deriving a transaction-based protocol-specific class that is compatible with the base class library.
The invented apparatus is an application programming interface (API), preferably coded in C/C++, for transparently routing data between sockets in such an IP transport. The API includes a message buffer data structure defining a protocol-generic parent class, message, source-address and data fields; a message creation mechanism for creating a message and adding it to the message buffer data structure; and a protocol creation mechanism for deriving a protocol-specific child class that renders new protocol-specific parameters for use within the message buffer data structure.
A C/C++ application programming interface (API) is proposed that allows any existing protocol to be routed between transmission control protocol (TCP) or UDP sockets. The invented API, referred to herein as MsgBuff, consists of specialized (for SS7 purposes) headers containing such information as linked and circuit identification code (CIC). This information is then followed by between zero and any (typically large) integer number of “tag-length-value” (TLV) trios. These trios may contain any type of data. In one embodiment, these data are byte representations of SS7 ISUP message parameters. In addition, several “application control” trios are created that are specific to illustrative embodiments of the invention.
The API may be rendered, for example, on a Solaris Sparc, Solaris x86 and Windows platform. Those of skill in the art will appreciate that other platforms, within the spirit and scope of the invention, may be used.
The primary advantage to the MsgBuff API is one of extensibility and non-reliance on the encapsulated protocol. In fact, the data that are encapsulated need not be a defined protocol at all. The API allows further use by any IP or SS7 protocol. Additional protocols are supported by deriving parameter objects from a generic base object. For example, transaction-based protocols such as a session-initiated protocol (SIP), a simple gateway monitoring protocol (SCMP), etc., may be provided in accordance with, and within the spirit and scope of, the invention. Other (non-protocol) data can be used directly by using the construction method described and illustrated herein.
The invented API can be used in any IP environment where a defined protocol is needed to send any encapsulated data stream. In accordance with one embodiment of the invention, the API requires the supported C/C++ header files as well as the platform-appropriate library. Those of skill in the art will appreciate that the data are transmitted over the Internet transparent to the transport protocol. Thus, the invention may be thought of as involving novel tunneling method and apparatus.
The invention thus represents a novel tunneling protocol.
Still referring to
Those of skill in the art will appreciate that the two methods may be combined, as indicated by the dashed line between blocks 202 and 204 in
The MsgBuff library consists of a base C++ class named MsgBuff. The primary purpose of the base class is to provide a structured approach to defining a mechanism for tunneling any existing protocol over an IP transport. This is accomplished by deriving a new protocol-specific class from the base MsgBuff class and overriding appropriate structures and methods where necessary. First, the Msgbuf class will be described in detail. Second, an example of how a protocol class may be created using the MsgBuf class will be described.
The MsgBuff library consists of several C++ source and header files, to be described in detail below. Current implementations exist on the Solaris Sparc, Solaris x86 and Windows platform. As the source and header files conform to ANSI-specifications, the library can be compiled on any platform using an ANSI-compliant compiler.
The library was created specifically to tunnel Signaling System 7 (SS7) protocols across a pair of Unix Domain Protocol (UDP) sockets. However, it is designed more generally to provide tunneling/transport functionality using any industry- or user-defined protocol. For example, the library has been extended to support Telephone User Part (TUP) and Transaction Capabilities Application Part (TCAP). In addition, it has been used to derive a protocol, available from Cisco Systems, Inc., useful for controlling telephony bearer circuits. While these embodiments so far have been SS7- and telephony-centered protocols, the base MsgBuff class, within the spirit and scope of the invention, are extensible for use with any transaction-based protocol. Examples include Session Initiated Protocol (SIP), Simple Gateway Monitoring Protocol (SGMP), etc.
The following annotated C/C++ source code is further illustrative of message buffer data structure 12. Those of skill in the art will appreciate that the annotations are set off from the source code by the standard double-backslash (//) followed by the annotation
typedef struct buff {
This field identifies the protocol of which this buffer is a part. A central enumeration is kept containing any defined protocols.
typedef enum {
This field identifies the protocol-specific message contained within the buffer. Values for this field are typically an enumerated definition. For example:
This field provides a basic sequencing mechanism for incoming and outgoing messages.
mlength:
This field indicates the overall length of the data buffer.
processId:
This field provides space to identify the identifier sending application.
offsetHash:
This field is used internally by the MsgBuff-derived classes to mark individual parameter units within the data array.
numPayloadPresent:
This field is a simple count of the encapsulated parameter data units within the data array.
ipAddr:
This identifies the IP address of the sending machine in a X.X.X.X format
mdata:
This is the data buffer used for holding 0 or more protocol-specific data parameters. Its basic format is shown below:
Each tag represents a protocol-specific, message-particular data parameter. The length of the parameter is defined by the length field, and the data structure itself is contained within the value field. Each tag-length-value (TLV) trio is placed as an entry one after the other within the mdata array. The beginning position of each trio is recorded in the offsetHash integer array. Up to forty total TLV trios can be defined for each buffer. Additionally, each derived child class may define multiple base TLV trios for the defined protocol. These trios would be present in all messages of that protocol type. The user protocol includes appropriate identifiers necessary for establishing user-user communication sessions. Examples might include SS7 linkset and CIC identifiers. The child class would then provide access methods that retrieve these always-present parameters from the buffer prior to accessing any non-mandatory parameters within the buffer.
The base MsgBuff class consists of base class constructors (virtual, copy, and assignment) and generic access methods for the private data. The main data component consists of a structure containing addressing, protocol, and message-specific parameters. Additionally, a variable length array is provided for transporting multiple protocol-specific data units. These units are used to form a TLV trio that is then inserted at the end of the data array within the buffer structure.
The following source code illustrates an ISUP message type and how easily a particular message type is enumerated in accordance with the invention.
typedef enum {
regApp,
deregApp,
isuplam,
isupAcm,
etc.
}IsupMsgTypes;
The following source code illustrates a TCAP message type.
typedef enum {
tcapRegApp,
tcapDeregApp,
tcapQueryWithPermission,
tcapQueryWithoutPersimission,
tcapConversationWithPermission,
tcapConversationWithoutPermission,
tcapResonse,
tcapUniDirectional
}TcapMsgTypes;
The following source code illustrates a media access control (MAC) message type.
typedef enum {
macRegApp,
macDeregApp,
macQtst,
macCcot,
macLpbk,
macStop,
macRsrv,
macUsrv,
macErrm,
macApng,
macVxml,
macXfer,
macXfrs,
}MacMsgTypes;
The following source code illustrates various payload types that would be carried as a TLV. Those of skill in the art will appreciate that they represent ISUP, TCAP and MAC tag values, in that order. The illustrated cic and linkset enumerations are examples of header information.
typedef enum {
// The following would have their own access methods defined
cic,
linkset,
// The rest would be accessed using the generic payload methods
accessDelivery,
backwardCallingIndicators,
etc.
}IsupTagValues;
typedef enum {
// These would be accessed using the generic payload methods
tInfoEntity,
dialogEntity,
componentEntity
}TcapTagValues;
typedef enum {
// The following would have their own access methods defined
asmid,
startCircuit,
endCircuit,
msgStatus,
serviceState,
iiDigit,
uui,
// The rest would be accessed using the generic payload methods
errorMarg,
ani,
dnis,
dest,
macEntity1,
macEntity2,
etc.
}MacTagValues;
The following source code illustrates generic size definitions for message header and maximum message buffer size, in that order.
#define MSGHDRSIZE (sizeof(msgBuffer)−MAX_DATA)
#define MAX_MSGBUFF_SIZE (MSGHDRSIZE+MAX_DATA)
The following source code illustrates the base message buffer class and how straightforwardly API 10 permits certain parameters to be initialized or established, in the form of questions that might be asked of, or demands that might be placed on, the interface. In other words, the following source code illustrates in detail one implementation of the method blocks shown in
classMsgBuff
{
public:
MsgBuff(msgBuffer*);
virtual˜MsgBuff( );
The following source code illustrates how API 10 facilitates various functions including, for example, a determination of how many TLVs are in a message, which protocol is represented by a message and what the message control is.
// How many TLVs are there?
inline getNumPayload( ) const
// Get the raw msgBuffer structure.
inline msgBuffer*getBuffer( )
// What kind of protocol does this buffer represent?
inline void setProtocol(int type)
inline int getProtocol( )
//What kind of ISUP, TCAP, MAC, etc message in this?
//Could be isuplam, tcapUniDirectional, macCcot, etc.
inline int getMsgType( ) const
inline int getProcessId( ) const
inline void setProcessId(int id)
inline void setIpAddr(char*addr)
inlinechar*getIpAddr( ) const
inline void setSeqNum(int i)
inline int getSeqNum( ) const
// Pure virtual parent functions
virtual void addPayload(int type, void*payload, int size)=0;
virtual int getPayload(int index, void** returned PayloadPointer)=0;
virtual int getPayloadType(int index)=0;
private:
msgBuffer buff;
int tlvOffset;
};
The following source code illustrates a typical Child ISUP message buffer class.
The following source code illustrates a typical Child TCAP message buffer class.
The following source code illustrates a typical Child MAC message buffer class.
The following source code illustrates the creation of message buffers.
TcapMsgBuff*tcapMb=new TcapMsgBuff(tcapQueryWithPermission);
tcapMb→addPayload(tInfoEntity, &InforStruct, sizeof(TInforStruct));
tcapMb→addPayload(componentEntity, &firstComponentStruct,
tcapMb→addPayload(componentEntity, &secondComponentStruct,
tcapMb→addPayload(dialogEntity, &dialogStruct, sizeof(DialogStruct));
msgBuffer*buff=tcapMb→getBuffer( );
retCode=socket→send((void*)&buff, MSGHDRSIZE+buff→mlength);
IsupMsgBuff*isupMb=newIsupMsgBuff(isupIam, Is, cic);
auto_ptr<Param>parm(creator→CreateParam(forwardCallingIndicators));
isupMb→addParam(parm);
msgBuffer*buff=isumMb→getBuffer( );
retCode=socket→send((void*)&buff, MSGHDRSIZE+buff→mlength);
MacMsgBuff*macMb=new MacMsgBuff(macQtst, asmId, status, serviceState,
macMb→addPayload(ani, &aniStruct, sizeof(AniStruct));
macMb→addPayload(dnis, &dnisStruct, sizeof(DnisStruct));
msgBuffer*buff=macMb→getBuffer( );
retCode=socket→send((void*)&buff, MSGHDRSIZE+buff→mlength);
The following source code illustrates the enumeration of the various illustrative MsgBuff protocol types including ISUP, TCAP, TUP, MEDIA and FOO, in that order.
typedef enum
{
IsupSvc,
TcapSvc,
TupSvc,
MediaSvci,
Foo
} MsgBuffProtocolTypes;
When a new protocol is to be created, the MsgBuff object is used to derive the protocol-specific child class. For instance, the base MsgBuff class may be used to create a ISDN User Part (ISUP) child IsupMsgBuff class that is used to transport SS7 ISUP messages over UDP sockets. Each child class receives base class functionality that supports protocol identification, message type specification, and addressing information. These are not to be overridden by the child class. In addition, the base class specifies several virtual methods that must be overridden by the protocol-specific child class. These methods are primarily data-related and are customized to support the new protocol.
An example of a generic ‘FOO’ protocol implementation is presented below:
typedef enum {
firstParameter,
sceondParameter,
thirdParameter,
} FooTagValues;
typedef enum {
fooMessage1,
fooMessage2,
fooMessage 3,
}FooMsgTypes;
class FooMsgBuff:public MsgBuff
{
public:
FooMsgBuff(msgBuffer*);
FooMsgBuff(int packageType);
// Example FOO parameter specific method
inline unsigned int getPackageType( ) const
{
};
//Parent virtual functions define for child FOO
void addPayload(int type, void*payload, int size);
int getPayload(int index, void**payload);
int getPayloadType(int index);
private:
};
These examples show how various protocol messages can be created using the MsgBuff-derived protocol classes for transport over a generic UNIX socket.
// Create a new FOO-specific MsgBuff object of message type fooMessage1
FooMsgBuff*fooMb=new FooMsgBuff(fooMessage1);
// Add various FOO-specific structures to the base MsgBuff data buffer
foo Mb→addPayload(firstParameter, &firstParmStruct, sizeof(FirstParmStruct));
fooMb→addPayload(secondParameter, &secondComponentStruct,
fooMb→addPayload(thirdParameter, &thirdComponentStruct ,
// Extract the buffer transport structure and send over the outgoing UNIX socket
msgBuffer*buff=fooMb→getBuffer( );
retCode=socket→send((void*)&buff, MSGHDRSIZE+buff→mlength);
This code example shows how an application can receive and decode an incoming generic MsgBuffer data array received over a UNIX socket:
Table I immediately below illustrates the ISUP message types that may be enumerated in accordance with one embodiment of the invention.
Table II immediately below illustrates various parameter types and tags that may be enumerated for ISUP messages in accordance with one embodiment of the invention.
The following source code illustrates a driver that may be used to create, send and read a message over a socket.
Finally, those of skill in the art will appreciate that the invented method and apparatus described and illustrated herein may be implemented in software, firmware or hardware, or any suitable combination thereof. Preferably, the method and apparatus are implemented in software, for purposes of low cost and flexibility. Thus, those of skill in the art will appreciate that the method and apparatus of the invention may be implemented by a computer or microprocessor process in which instructions are executed, the instructions being stored for execution on a computer-readable medium and being executed by any suitable instruction processor. Alternative embodiments are contemplated, however, and are within the spirit and scope of the invention.
Having illustrated and described the principles of our invention in a preferred embodiment thereof, it should be readily apparent to those skilled in the art that the invention can be modified in arrangement and detail without departing from such principles. We claim all modifications coming within the spirit and scope of the accompanying claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5826030 | Hebert | Oct 1998 | A |
| 6088749 | Hebert et al. | Jul 2000 | A |
| 6311238 | Hebert | Oct 2001 | B1 |
| 6480597 | Kult et al. | Nov 2002 | B1 |
| 6516355 | Hartmann et al. | Feb 2003 | B1 |
| 6567377 | Vepa et al. | May 2003 | B1 |
| 6594685 | Mishra et al. | Jul 2003 | B1 |
| 6801940 | Moran et al. | Oct 2004 | B1 |
| 20040015499 | Silverman et al. | Jan 2004 | A1 |
