Patent Application
20080019391
In one embodiment, communications over system 100 use a layered communication architecture including seven communication layers L1 through L7. The physical layer (L1) is the lowest layer in the architecture, and the application layer (L7) is the highest. Each layer L1 through L6 provides services (e.g., performs error-correction, data routing, encryption, etc.) to the next highest layer according to a specific protocol. Thus, for example, the presentation layer performs presentation layer services (e.g., identifying and selecting a transfer syntax) for the application layer data, the network layer performs network layer services (e.g., data routing services, receipt confirmation, etc.) for the transport layer data, etc.
In communications between computer systems, data to be sent from a first computer system (e.g., system 110) to a second computer system (e.g., system 120) begins at a layer in the first system. A layer processing package at the sending system (e.g., system 110), which may include one or more software, firmware, and/or hardware modules designed to process data at a given layer (e.g., software programs written in C, C++, Java, or other known programming languages; network interface cards designed to send and receive network communications, etc.), will encapsulate the data with a layer-specific header and optionally a layer-specific footer, also referred to as a trailer. The header and optional footer contain information that instructs the corresponding receiving processing package at the receiving system (e.g., system 120) how to process the received data. In one embodiment, the header appears before the data being sent, while the footer follows the data. The term “header,” as disclosed, may refer to a header and/or footer used to encapsulate data. Because a header is appended to data at a specific layer, the header may be associated with, and is processed according to, a specific protocol that is used at the layer used to communicate data between different computer systems.
In one embodiment, data to be communicated from one system (e.g., system 110) to another system (e.g., system 120) may originate at the application layer (L7). The original data is then encapsulated with an L7H header, and both the L7H header and the L7 data may be passed down to a next lower layer (e.g., presentation layer L6). The L7H header together with the L7 data are referred to as a protocol data unit (PDU) for layer seven, or L7 PDU. That is, the L7H header together with the L7 data are a complete data unit that will eventually be processed by a corresponding L7 processing package (e.g., software, firmware, and/or hardware module for processing the L7 data) at system 120 according to the features and requirements of the L7 protocol used by that package. In
When the L6 processing package receives the L7 PDU, it performs a service on the L7 PDU. For example, at system 110, the L6 processing package may further encapsulate the L7 PDU with a L6H header. The L6H header may contain information that instructs the receiving L6 processing package at system 120 how to process the received data. Thus, the L6H header is associated with, and is processed according to, a specific protocol that is used to communicate data between L6 processing packages on different computer systems. Because the L7 PDU is serviced by the L6 processing package, the L7 PDU encapsulated by the L6H header is referred to as a service data unit (SDU) of L6, or an L6 SDU. In
In one embodiment, the above described encapsulation process continues all the way down the protocol stack. Thus, the L6H header and L6 SDU constitute a L6 PDU, which is passed to L5 and encapsulated with a L5H header to become the L5 SDU (
Upon receiving the message encapsulated with an outermost L2 header (i.e. an L2 PDU), the receiving system 120 performs the inverse process as the sending system 110. That is, an L2 processing package at receiving system 120 processes the L2H header according to the L2 protocol, thereby performing a service on the L2 SDU. The L2 SDU, which is an L3 PDU, is then passed to L3 and is processed by the L3 processing package. The L3 processing package processes the L3H header according to the L3 protocol, therefore performing a service on the L3 SDU. The L3 SDU, which is an L4 PDU, is then passed to L4 and is processed by the L4 processing package. This process continues until the L7 PDU is received by the L7 processing package at system 120. In one embodiment, the L7 processing package at computer system 120 then processes the L7 header according to the L7 protocol, and the original L7 data may then be processed by the L7 application at system 120.
It should be noted that not every entity that processes data according to the disclosed embodiments includes processing packages for all seven layers. For example, in one embodiment, routers that process PDUs may be designed to only process the first three layers (i.e. physical, data link, and network layers), as they only need to route higher layer data through a network without further processing the data. In another embodiment, for example, certain application programs may not require the services of certain layers (e.g., session layer, presentation layer, etc.). Therefore, not all layers are necessarily present in every communication made using the disclosed communication architecture. Furthermore, in another embodiment, a layer may employ more than one protocol to process data. Thus, a protocol, which refers to a set of steps performed in processing data, may include a number of protocols that each include a subset of the set of steps.
The uniform message header framework implemented according to the disclosed embodiments uses a standard set of header fields, referred to as a “framework header,” to implement a common protocol, referred to as a frame header protocol. This protocol is used to process framework headers at each of a plurality of layers in a communication stack. The framework header includes mandatory header fields and optional header fields. Each of these fields may have a predetermined set length. The mandatory fields are included in the PDU header for every layer that uses the framework header protocol. The optional fields may or may not be included in the framework header, depending on the layer and the protocol being used. Using the framework header to encapsulate different layers in the communication stack reduces the number and complexity of processing packages necessary to process different PDUs at different layers.
The PDUs described hereafter will be discussed in terms of a header portion, which in certain embodiments includes a framework header, and a data portion, which may include an SDU and/or other message data. The framework header may be used to encapsulate a set of layers. For example, in one embodiment, the framework header is used in each of the application, presentation, session, and transport layer headers. In another embodiment, the framework header is appended to layers 2 through 7 of the protocol stack. It should be noted that although the disclosed embodiments describe a layered communication architecture having the seven layers described in the OSI communication architecture, the uniform message header framework disclosed herein may be used for any layered communication architecture. In addition, the uniform message header framework described herein may be used to add new layers to existing communication protocols or to create entirely new layered communication stacks that employ new communication protocols.
In the embodiment depicted in
For example, mode field 202a indicates whether PDU 200 is a connectionless or connection-oriented PDU. In a connectionless mode of communication, there is no explicit link between the PDU of a given message and the PDU of a previous or subsequent message. In a connection-oriented mode of communication, there is an explicit link defined in the PDU that relates a given message to a previous or subsequent message. Connectionless and connection-oriented PDUs include different optional headers. In PDU 200, mode field 202a is set to 0, indicating a connectionless PDU. In another embodiment, the mode field may be set to 1, which indicates a connection-oriented PDU. It should be noted that the value of the fields used for designating states, status, etc., are not limited to those described herein. Any values or number of bits may be used in these fields to designate a desired state, status, etc., of PDU 200. The data in mode field 202a informs the processing package of the meaning of the data following mode field 202a, and thus instructs the processing package how to interpret the remainder of PDU 200. For example, in one embodiment, if the mode field indicates a connectionless PDU (e.g. has a value of 0), then the processing package processing the PDU knows that the 8 bits following the mandatory header (i.e. octet #1) may correspond to version ID field 204, the next 8 bits (i.e. octet #2) may correspond to action ID field 206, the next 16 bits (i.e. octets #3 and 4) may correspond to service ID field 208, the next 24 bits (i.e. octet #5-7) may correspond to a block array 210, and the final remaining bits, which may include any number of octets, may correspond to an SDU. Other values may be used in field 202a to designate other types of PDUs.
Field 202b is a connection field that contains information related to a sender or receiver of PDU 200. For connectionless PDUs, such as the one depicted in PDU 200, a processing package processing PDU 200 will ignore any information in field 202b. Field 202c is a reserved field that may be used for additional functions by a processing package or other system. Fields 202d-202h are connectionless mode format fields. The data in these fields instructs the processing package whether each of PDU fields 204, 206, 208, 210, and 212 are set and thus include information to be used by a processing package. For example, the data in field 202d (i.e., bit #0) informs the processing package whether version ID field 204 is set. If the data in field 202d has a “set” value (e.g., has a value of 1), then the version ID field 204 is set, and the processing package knows to process the bits in octet #1 as version ID field 204.
In a similar manner, the data in fields 202e, 202f, 202g, and 202h inform the processing package whether respective action ID field 206, service ID field 208, block array field 210 and SDU field 212 are set and should be processed as corresponding header fields by the processing package. If any of the format field bits have “not set” values (e.g., a value of 0), then the corresponding PDU header field is not set and the processing package will process the PDU accordingly. For example, in one embodiment, if field 202d is 0, then the processing package receiving the PDU assumes version ID field 204 is present, but will ignore any data stored in the version ID field 204. In another embodiment, if field 202d is 0 and, for example, field 202e is 1, then the processing package receiving the PDU assumes version ID field 204 is not present, and processes octet #1 as action ID field 206 and other optional header fields in a similar manner depending on the data in corresponding fields 202f, 202g, and 202h.
Version ID field 204, if set (e.g., format field 202d has a value of 1), identifies the version of the connectionless protocol chosen by the entity that created PDU 200. Accordingly, optional field 204 identifies to a receiving processing package the version of a protocol to use in processing the data in PDU 200.
Action ID field 206, if set (e.g., format field 202e has a value of 1), identifies the action of the connectionless protocol taken or desired by the entity that created PDU 200 (e.g., a processing package at computer system 110). The particular action identified depends on the service and the protocol version used. For example, in one embodiment where connectionless messages are transmitted, actions may include transfer data, report error, respond to request, etc.
Service ID field 208, if set (e.g., format field 202f has a value of 1), identifies either the previous service (e.g., layer) in the stack that just processed data (for outgoing messages) or the next service (e.g., layer) in line to process data (for incoming messages). In one embodiment, if service ID field 208 is set, then either block array field 210 or the SDU field 212 must also be set. If service ID field 208 is not set (e.g., format field 202f has a value of 0), then PDU 200 is either located at the first service (e.g., layer) to process data for an outgoing message, or is located at the last service (e.g., layer) to process data for an incoming message.
Block array field 210, if set (e.g., format field 202g has a value of 1), may include block array overhead (e.g., octet #5), and may include protocol control information (PCI). The PCI is protocol specific information to be interpreted by a processing package according to the service, protocol version, and action indicated in the PDU header. Although shown as three octets, block array field 210 may include any number of octets. In one embodiment, the block array overhead indicates the number of octets included in block array field 210.
SDU field 212, if set (e.g., format field 202h has a value of 1), includes an SDU (e.g., a PDU for the next highest layer). In one embodiment, because the SDU is a PDU for the next highest layer, and the SDU contains at least the same mandatory header fields 202 as PDU 200. Furthermore, the PDU for the next highest layer may include a further SDU for an even higher layer. In this manner, PDU 200 may include a set of recursive SDUs, each encapsulated by a header that includes at least the mandatory header fields 202 shown in
In the embodiment depicted in
For example, the data in mode field 302a indicates whether PDU 300 is a connectionless or connection-oriented PDU. Connection-oriented PDU 300 may include different optional header fields from connectionless PDU 200 shown in
Field 302b is an originator field that identifies the source of PDU 300 (e.g., whether the PDU is sent by a client entity or a server entity). Because connection-oriented services involve the exchange of information between two entities (e.g., a connection, or conversation), the processing packages in a connection-oriented communication must be able to distinguish whether PDU 300 is destined for a client (e.g., an entity using services of another entity) or a server (e.g., an entity providing services to another entity). Thus, field 302b indicates the originator entity of PDU 300.
Field 302c is a reserved field that may be used for additional functions by a processing package or other system. Fields 302d-302h are connection-oriented mode format fields. The data in these fields instructs the processing package whether each of PDU fields 304, 306, 308, 310, and 312 are set and thus include information to be used by a processing package. For example, the data in field 302d (i.e., bit #0) informs the processing package whether connector ID field 304 is set. If the data in field 302d has a “set” value (e.g., a value of 1), then the connector ID field 304 is set, and the processing package knows to process the bits in octets #1 and 2 as connector ID field 304.
In a similar manner, the data in fields 302e, 302f, 302g, and 302h inform the processing package whether respective action ID field 306, service ID field 308, block array field 310 and SDU field 312 are set and should be processed as corresponding header fields by the processing package. If any of the format field bits have a “not set” value (e.g., a value of 0), then the corresponding header field is not set and the processing package will process the PDU accordingly. For example, in one embodiment, if field 302d is 0, then the processing package receiving the PDU assumes connector ID field 304 is present, but will ignore any data stored in the connector ID field 304 (e.g., will ignore any data stored in octets #1 and 2). In another embodiment, if field 302d is 0 and, for example, field 302e is 1, then the processing package receiving the PDU assumes connector ID field 304 is not present, and processes octet #1 as action ID field 306 and other optional header fields in a similar manner depending on the data in corresponding fields 302f, 302g, and 302h.
Connector ID field 304, if set (e.g., format field 303d has a value of 1), identifies a connector for a client entity that is using the connection. Accordingly, field 304 instructs a receiving processing package which client entity is associated with the connection. The particular connector identified in field 304 depends in part upon the service being performed on the PDU.
Action ID field 306, if set (e.g., format field 302e has a value of 1), identifies the action of the connection-oriented protocol taken, or desired, by the client and server entities associated with PDU 300. The particular action identified depends on the service and the protocol version used, and is negotiated by the client and server during connection establishment. For example, in one embodiment where connection-oriented messages are transmitted, actions may include initiate connection, accept connection, reject connection, transfer data, query state, verify state, report error, initiate disconnect, accept disconnect, reject disconnect, abort connection, etc.
Service ID field 308, block array field 310, and SDU field 312, if set, may include similar information and perform similar functions as described above in connection with fields 208, 210, and 212 of PDU 200.
The disclosed PDU and framework header is exemplary for any layer of a layered communication architecture. For example, in one embodiment, layers 4 through 7 of an OSI-type stack (e.g., the transport, session, presentation, and application layers) may use a framework header structure similar to that shown in
As described in the examples above, by using the uniform message header framework of the disclosed embodiments, a single processing package can process multiple layers in the protocol stack using a common instruction set. The framework header may include mandatory header fields containing control information and optional header fields that contain additional control information for processing packages. In one embodiment, the mandatory and optional header fields include those shown in
The disclosed uniform message header framework may be applicable to any type of computer system or other system that implements layered communications. For example, the disclosed embodiments may be used to facilitate communications between personal computers (PCs), mobile devices (e.g., laptop computers, palm-top computers, cellular phones, PDAs, etc.), network-enabled appliances (e.g., Internet-enabled home appliances), automobiles, machines and equipment (e.g., backhoe loaders, dozers, dump trucks, other work-related machines, etc.), routers, switches, and other devices.
In addition, the disclosed uniform message header framework may be used on any of a number of layers of data in a layered communication system. For example, the disclosed framework header may be used for the top four layers (e.g. L4, L5, L6, and L7) of a seven-layer communication stack such as an OSI-type stack that includes an application layer, presentation layer, session layer, transport layer, network layer, data link layer, and physical layer. Further, the framework header may be used for other layers of other types of communication stacks. In one embodiment, the disclosed framework header may be used to encapsulate existing protocol layers, such as the FTP protocol or the TCP protocol. For example, the disclosed framework header may be used to add an encryption layer and/or error correction layer, among other layers, to one or more existing communication protocols. Or, the framework header may be used to create a new protocol stack consisting of entirely new protocols.
In one embodiment, a single processing package may be used to process different layers of the protocol stack, thereby decreasing the costs and complexity of a layered communication system. Furthermore, the uniform structure of the header that may be used for different protocols allows new protocols or layers to be easily added to the communication system.
It will be apparent to those skilled in the art that various modifications and variations can be made to the uniform message header framework. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed uniform message header framework. It is intended that the specification and examples be considered as exemplary only, with a true scope being indicated by the following claims and their equivalents.
