CA2508748A1 - Apparatus for implementing a lightweight, reliable, packet-based transport protocol - Google Patents
Apparatus for implementing a lightweight, reliable, packet-based transport protocol Download PDFInfo
- Publication number
- CA2508748A1 CA2508748A1 CA002508748A CA2508748A CA2508748A1 CA 2508748 A1 CA2508748 A1 CA 2508748A1 CA 002508748 A CA002508748 A CA 002508748A CA 2508748 A CA2508748 A CA 2508748A CA 2508748 A1 CA2508748 A1 CA 2508748A1
- Authority
- CA
- Canada
- Prior art keywords
- protocol
- field
- frame
- frames
- ethernet
- 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.)
- Abandoned
Links
- 238000007726 management method Methods 0.000 claims abstract description 9
- 230000007246 mechanism Effects 0.000 claims description 22
- 230000004044 response Effects 0.000 claims description 17
- 238000005538 encapsulation Methods 0.000 claims description 14
- 230000011218 segmentation Effects 0.000 claims description 2
- 230000003139 buffering effect Effects 0.000 claims 1
- 230000006870 function Effects 0.000 abstract description 5
- 230000006855 networking Effects 0.000 abstract description 2
- 238000000034 method Methods 0.000 description 12
- 238000010586 diagram Methods 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000008859 change Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 101100365729 Drosophila melanogaster Shrm gene Proteins 0.000 description 1
- 101100365725 Mus musculus Shroom3 gene Proteins 0.000 description 1
- 241001125929 Trisopterus luscus Species 0.000 description 1
- 101100365726 Xenopus laevis shroom3 gene Proteins 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000003090 exacerbative effect Effects 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 235000012222 talc Nutrition 0.000 description 1
Classifications
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- 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/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/29—Flow control; Congestion control using a combination of thresholds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/37—Slow start
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- 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/22—Parsing or analysis of headers
-
- 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/10—Streamlined, light-weight or high-speed protocols, e.g. express transfer protocol [XTP] or byte stream
-
- 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/26—Special purpose or proprietary protocols or architectures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
A fast, lightweight, reliable, packet-based protocol (ABC) that operates independent of the type of networking protocol used by the underlying physical layer of the network is disclosed. More specifically, the packet based protocol operates independently of or is capable of encapsulating over physical layer protocols such as but not limited to MAC, Ethernet, Ethernet II, HARD or IP. The protocol defines at least three different types of frames including Information frames, Supervisory frames, and Unnumbered frames. In various embodiments of the invention, the Information, Supervisory, and Unnumbered frames include DSAP and SSAP field with semantics which are sufficiently large to support the various physical layer protocols that may be used on the network. The Information frames, Supervisory frames, and Unnumbered frames also have the ability to support urgent data delivery and certain memory management functions. The protocol is further capable of support the multiplexing of layers higher than the protocol so that multiple higher layer applications may share the same connection. Finally, the protocol of the present invention supports both flow control and congestion control, to help reduce the incidence of lost or dropped packets at a receiving node or over the network respectively.
Description
APPARATUS AND METHOD FOR A LIGHTWEIGHT, RELIABLE, PACKET-BASED TRANSPORT PROTOCOL
Related Applications The present invention is related to U.S. Application Serial NLUnber 10/313,306 (attorney docket number ANDIP017) filed on December 6, 2002 entitled "A
Scalable Networlc Attached Storage System" by Thomas Edsall et. al. and U.S.
Application Serial Number 10/313,745 (attorney doclcet number ANDIP023) filed on December 6, 2002 entitled "Apparatus and Method for a High Availability Data Networlc Using Replicated Delivery" by Gai Silvano et. al., both filed on the same day and assigned to the same assignee as the present invention, and incorporated herein by reference for all purposes.
BACKGROUND OF THE INVENTION
1. Field of the Invention The present invention relates to data networks, and more particularly, to a fast, lightweight, reliable, packet-based transport protocol that operates independent of the type of underlying protocol used by the network.
Related Applications The present invention is related to U.S. Application Serial NLUnber 10/313,306 (attorney docket number ANDIP017) filed on December 6, 2002 entitled "A
Scalable Networlc Attached Storage System" by Thomas Edsall et. al. and U.S.
Application Serial Number 10/313,745 (attorney doclcet number ANDIP023) filed on December 6, 2002 entitled "Apparatus and Method for a High Availability Data Networlc Using Replicated Delivery" by Gai Silvano et. al., both filed on the same day and assigned to the same assignee as the present invention, and incorporated herein by reference for all purposes.
BACKGROUND OF THE INVENTION
1. Field of the Invention The present invention relates to data networks, and more particularly, to a fast, lightweight, reliable, packet-based transport protocol that operates independent of the type of underlying protocol used by the network.
2. Background of the Invention The most popular transport protocol in use today is the Ti°ahs~raissiofz Control P~°otocol (TCP) defined in the framework of the Irxterrzet Protocol (IP) Suite. The TCP protocol provides upper protocol layers and/or applications with a reliable, connection-oriented, strictly in-order delivery, byte-stream transport service. TCP
achieves reliability by means of an acknowledge-and-retransmission mechanism.
Generally speaking, a receiving TCP entity acknowledges every packet it receives from the transmitting TCP entity. When one of such acknowledgments is not received within a certain period of time (called the Retf°ansmissioh Tiyoeout), the transmitting TCP entity assumes that the corresponding paclcet has been lost in the network and retransmits it. This retransmission mechanism has been improved over the years in order to make it more efficient. For example, an algoritlun called Fast Reti°ansJ~zit has been added to TCP to trigger a retransmission of a missing packet well before a the retransmission timeout occurs. Also, the retransmission timeout has been made adaptive to the network size and load by adding an estimator of the round-trip-time, i.e., the time it talces for a TCP packet to reach its destination plus the time necessary for its acknowledgment to come back.
The TCP protocol also provides a flow control function, which is defined as the ability of the receiving node to control the rate at which paclcets are transmitted to it to prevent the overflow of its input buffer. To this end, TCP employs a flow control mechanism called sliding wiv~dow. A receiving TCP entity continuously informs the transmitting TCP entity about the amount of free input buffer (the so called offe~~d wiyadow). When this amount drops to zero, the transmitting TCP entity refrains from transmitting any further data to the receiving entity until new space becomes available in the input buffer.
Another important capability built into TCP is the congestion control function.
It has already been noted that when a transmitting TCP entity does not receive an acknowledgment, it assumes the packet was dropped by the networlc. There are many reasons for which the network can drop a packet, e.g., data corruption, faulty lines and/or networlc, buffer congestion, etc. Of all those reasons, congestion is the by far the most common, especially in large networks such as the Internet. Therefore, when an aclalowledge goes missing, TCP not only assumes that a packet was dropped, it also assumes that the reason for this drop is networlc congestion. A number of algoritlnns such as Slow Start and Fast Recovery have been embedded into TCP
in order to deal with congestion. The pwpose of such algoritlnns is to tluottle doom the transmission rate in different ways depending on the severity of the congestion detected in the network.
One problem with TCP is that the three functions mentioned above, i.e., reliable delivery, flow control, and congestion control as well as other functionality make it an extremely complex protocol from the implementation standpoint. As a result, most network nodes typically implement TCP as a software module embedded in the operating system. Clearly this solution is not particularly fast and also consumes CPU cycles that could be used to run user applications. There are also a few TCP implementations that rely on micro-controller chips and special software (micro-code) to offload the system CPU from the task of running TCP. This solution is faster and more efficient than the previous one, but is still inadequate for high speed (i.e., mufti gigabit per second) networks.
A fast, lightweight, reliable, packet-based protocol that operates independent of the type underlying protocol layer is therefore needed.
SUMMARY OF THE INVENTION
To achieve the foregoing, and in accordance with the propose of the present invention, a fast, lightweight, reliable, packet-based transport protocol that operates independent of the type of the underlying protocols is disclosed. More specifically,.
this protocol, hereafter referred to as the ABC protocol, can be carried by protocols such as but not limited to IEEE 802.3, Ethernet, Ethernet II, HARD or IP. The ABC
protocol defines at least tluee different types of frames including Information frames, Supervisory frames, and Unnumbered frames. In various embodiments of the invention, the Information, Supervisory, and Unnumbered frames include Destination Service Access Point (DSAP) and Source Service Access Point (SSAP) fields which are sufficiently large to support the various applications that may be used on the network. The Information frames, Supervisory frames, and Unnumbered frames also have the ability to support urgent data delivery and certain memory management functions. The ABC protocol is ftirther capable of support the multiplexing of higher layer protocols so that multiple higher layer applications may share the same comlection. Finally, the ABC protocol of the present invention supports both flow control and congestion control, to help reduce the incidence of lost or dropped packets at a receiving node or over the networlc.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure lA is the header of an Information frame used by the ABC protocol of the present invention.
Figure 1B is the format of the Control field of the Information frame header of Figure lA according to the present invention.
Figures 1 C is the format of the Flags field of the Information frame header of Figure lA according to the present invention.
Figure 2A illustrates the header of a Supervisory frame of the ABC protocol of the present invention.
Figure 2B is the format of the Control field of the Supervisory frame header of Figure 2A according to the present invention.
Figure 3 illustrates the header of an UnnLUnbered frame used by the ABC
protocol of the present invention.
Figure 3B is the format of the Control field of the Unnumbered frame header of Figure 3A according to the present invention.
Figure 3C is the header of a XID frame used by the ABC protocol according to the present invention.
Figure 4 is illustrates the ABC protocol of the present invention layered on top of r a MAC layer, IP layer of a HARD layer according to various embodiments of the present invention.
Figure SA illustrates an Ethernet II frame format.
Figure SB illustrates the encapsulation of an ABC packet inside of an Ethernet II frame according to the present invention.
Figure SC illustrates the encapsulation of an ABC packet inside an HARD
packet, in turn, inside an Ethernet II frame according to the present invention.
Figure 6A illustrates the encapsulation of an ABC packet inside an IP
datagram according to the present invention.
Figure 6B illustrates the encapsulation of an ABC paclcet inside an HARD
packet, in turn inside an IP datagram according to the present invention.
Figure 7 is a diagram illustrating the cycle of the stop-and go flow control mechanism used by the ABC protocol of the present invention.
Figure 8 is a diagram illustrating an ABG protocol congestion window evolution over time according to the present invention is shown.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The fast, lightweight, reliable, packet-based transport protocol of the present invention, hereafter referred to as the ABC protocol, is a modification of the Logical Lint Control - Part 2 (LLC-Type 2) protocol. More specifically, the ABG
protocol of the present invention uses the state machine of the LLC Type 2 protocol without substantial modifications while modifying and extending certain aspects of LLC
Type 2, as described here. For more information on the LLC -Type 2, see Part 2;
logic Link Control, ANSI/IEEE Std. 802.2, 1998 Edition, incorporated in its entirety herein for all purposes.
Modifications to LLC-Type 2 The ABC protocol of the present invention modifies the LLC Type 2 protocol in tluee basic areas: addressing, flow and congestion control, and Out-of Band signaling.
Each LLC-Type 2 Protocol Data Unit (PDU) contains two address fields, the Destination Service Access Point (DSAP) and the Sol~rce Service Address Point (SSAP). Each of these fields is eight bits wide and includes seven bits of actual address information. The least significant bit (LSB) in the DSAP field is used to identify the DSAP address as either an individual or a group address. The least significant eighth bit in the SSAP field is used to identify the LLC PDU as either a command or a response, and is therefore sometimes referred to as command/response identifier bit. The ABC protocol of the present invention extends the LLC-Type addressing capabilities by having sixteen bit wide DSAP and SSAP fields. The semantic of the LSB for both fields remains the same as LLC-Type 2. The remaining fifteen bits, however, are now used for addressing pwposes with the DSAP and SSAP
fields respectively.
LLC-Type 2 relies on both the DSAP and SSAP fields in the LLC Type 2 header and the MAC source and destination addresses to identify a comzection.
Since the ABC protocol of the present invention operates independently of the underlying physical layer and can be used with almost any type of networking media, the semantics of the DSAP and SSAP fields have been slightly changed in such a way that connections are uniquely identified only by the DSAP and SSAP addresses.
A
media access control or MAC address is not needed with the present invention.
This modification enables the ABC protocol of the present invention to be very flexible and allows it to run on any underlying layer such as IP or Ethernet without any maj or modifications.
LLC Type 2 flow control is mainly intended for point-to-point lincs, while in ABC flow control is modified in order to work with an arbitrary munber of lines between a pair of ABC nodes. As far as congestion control is concerned, the most currently available LLC-Type2 specification includes an Annex, i.e., Aimex C, which defines optional congestion control techniques for bridged LANs. The congestion control technique therein described seems to be inadequate to deal with severe congestion and penalizes substantially a comlection from the bandwidth standpoint, especially if a network is large and the Round Trip Time (RTT) is considerable. ABC
replaces the Annex C technique with a congestion control mechanism very similar to the one employed by the TCP protocol, which is widely lmown to be both effective and efficient. Flow control and congestion control are described in detail later in this application.
Finally, ABC requires the mandatory implementation of the XID and TEST
frames for out-of band signaling, as specified in the LLC-Type2 specification.
Extensions to LLC-Type Z
The ABC protocol extends the LLC-Type 2 protocol, by adding some extra functionality, in the following areas: memory management and segmentation, support for iugent data, and higher layer/application multiplexing.
As far as memory management is concerned, ABC allows a transmitting entity to signal a receiving entity that it needs to allocate a new buffer for data, tluough the NEW BUFFER bit, or that a data unit has been completed and it can be delivered to the upper layer, through the END OF DATA bit.
ABC supports the delivery of urgent data to the destination ABC entity. When such an entity receives an Information frame marked urgent, the data contained in this frame is not buffered but immediately delivered to the upper layer protocol.
Finally, ABC allows multiple applications to share the same connection (i.e., having their packets sent using the same DSAP/SSAP pair. Application multiplexing is implemented in a way similar to TCP (Transmission Control Protocol) or UDP
(User Datagram Protocol), i.e., by means of two 16-bit fields called Source Port and Destination Port.
ABC Frame Types The ABC protocol of the present invention uses three different types of frames, similar to LLC-Type 2. The three types include Information frames, Supervisory frames and Ummmbered frames.
Referring to Figure lA, the header of an Information frame used by the ABC
protocol of the present invention is shown. The Information frame header 10 includes a total of six fields, each sixteen bits wide. The six fields include a DSAP
field, an SSAP field, a control field 12, a Flags field 14, and Source and Destination port fields respectively. The DSAP field identifies an ABC protocol connection at the destination node. The least significant bit is the Individual/Group bit as defined by the LLC-Type 2 specification. The remaining fifteen bits are used to identify the comiection on the destination node. The SSAP field identifies the ABC protocol connection on the source node. The least significant bit is the Command/Response bit as defined by the LLC-Type 2 specification. The remaining fifteen bits are used to define the comiection on the source code. Since fifteen bits in either the DSAP or the SSAP
fields are used as connection identifiers, a maximwn of 215=32768 connections can be active at an ABC node. In another embodiment of the present invention, the concatenation of the upper fifteen bits of the DSAP and the upper fifteen bits of the SSAP can be used as a comlection identifier to increase the maximum n Lunber of active connections, if needed. The DSAP and SSAP, fields are essentially the same as those defined by the LCC-Type 2 specification, except they are sixteen and not eight bits wide. The source Port field identifies the source application, while the Destination pout field identifies the destination application.
As illustrated in Figure 1B, the control field of an Information Frame is used to hold sequence numbers and control information. The control field 12 has its most significant bit always set to zero (0) according to the preferred embodiment.
The next seven bits represent the send sequence number N(S) of the sender. The first bit of the second byte is the Poll/Final bit as defined by the LLG-Type 2 specification.
The remaining seven bits represent the receive sequence number N(R) of the sender.
In Figure 1C, the various flags of the Flag field 14 are illustrated. These flags include from the most significant to the least significant bits, two bits to indicate the protocol version number (VERS), three memory management flags (HM, NB and EOD), and the urgent data flag (URG). The HM flag indicates if Hardware Memory management is supported or not. If this flag is set, the NB and EOD flags are considered valid. The New Buffer (NB) flag indicates that a new buffer must be allocated at the receiver to hold the data of the present and subsequent Information frames. The End of Data (EOD) flag indicates that this frame carries the last fragment of an upper layer data unit and, therefore, this data unit can be delivered and the buffer returned to the free pool. Finally, the urgent data flag (URG), when set, informs the receiving ABC entity that the data contained in this frame is urgent and must be delivered to the upper layer without being buffered. The remaining "Reserved" bits are available for the addition of new flags as needed.
Referring to Figure 2A, the format of the header of a Supervisory frame of the ABC protocol of the present invention is shown. The Supervisory frame header includes three fields, DSAP, SSAP and a Control field 22. The format of the header of a Supervisory frame 20 is essentially the same as the Supervisory frame of the LLC-Type 2 protocol, except the DSAP and SSAP fields are sixteen and not eight bits wide.
In Figure 2B, the Control field 22 is shown. The two most significant bits of the Control field 22 are set to, according to one embodiment, "10" for every Supervisory frame header 20. The next two bits (SS) identify the Supervisory frame type. The Supervisory flame types include Receiver Ready (RR) [SS=00], Receiver Not Ready (RNR) [SS=10], and Reject (RJT) [SS=O1]. The next four bits are unused while the Poll/Final bit is at the same bit position as the Information frame.
The seven least significant bits are used to represent the receive sequence number N(R) of the sender .
Referring to Figure 3A, the header of an Ummmbered frame used by the ABC
protocol of the present invention is shovm. The Ummunbered frame header 30 is similar to the Supervisory frame header 20, except the control field 32 is only eight bits wide. As illustrated in Figure 3B, the first two most significant bits are always set to "11" according to one embodiment, the fifth bit is the Poll/Find (P/F) bit, and all the remaining bits (M) specify the Ummmbered frame type. Table I below defines the ummmbered frames that are implemented with the ABC protocol of the present invention.
Table I
Command/Response Description MMMMM
SABME Command Set Asynchronous 11110 ~
Balanced Mode Extended:
used to initiate a comlection DISC Cormnand Disconnect: used 00010 to terminate a comiection UA Response Urmumbered 00110 Acknowledgement:
used to respond to SABME
or DISC Command DM Response Disconnect Mode: 11000 used to respond to non-SABME
frames received when a comlection is not yet started.
FRMR Response Frame Reject: used 10001 to Resume from Error Conditions.
XID Command/Response ~ Exchange Identification: ~ 11101 used to negotiate the window size Test Command/Response ~ Test: used to verify the ~ 00111 status of a remote ABC
station The XID Command/Response is used with the ABC protocol of the present invention only to communicate the receiver window size (RW). It therefore uses a simplified format compared to the LLC Type-2 version. With the LLC Type-2 version, every LLC protocol class supported by the sending entity must be listed.
Figure 3C illustrates the XID frame of the present invention. Following the Control Feld 32, there is an eight bit information field 34. The most significant bit is set to zero. The remaining seven bits convey the window size of the receiving entity (RW).
Encapsulation The ABC protocol of the present invention operates independent of the type of mderlying protocol. The ABC protocol can be used on top of Ethernet, Ethernet II, IP
or HARD. For a more detailed explanation of HARD, see the aforementioned U.S.
Application Serial Number 101313,745 (attorney docket number ANDIP023) filed on December 6, 2002 entitled "Apparatus and Method for a High Availability Data Network Using Replicated Delivery" by Gai Silvano et. al.
Referring to Figure 4, the ABC protocol 40 of the present invention is shown deployed either over an Ethernet MAC layer or an IP layer with or without HARD
in both cases. The encapsulation of the ABC protocol 40 of the present invention inside Ethernet/Ethernet II frames and IP datagrams, optionally using the high availability features of the HARD protocol are described below. The chief adva~ltage of encapsulating the ABC protocol inside IP datagrams is the ability to malce the ABC
protocol mutable. A disadvantage is that the hardware implementing the ABC
protocol may have to deal with IP fragmentation.
Referring to Figure SA, an Ethernet (or Ethernet II) frame format is shown.
The frame 50 includes a Destination Address (DA) field 52, a Source Address (SA) field 54, an Ethernet Type (Etype) field 56, a data field 58, and a Frame Checlc Sequence (FCS) field 59. In order to encapsulate ABC frames inside Ethernet frames, a new Ethernet type is needed to identify the ABC protocol data unit carried as an Ethernet Data field 50. In one embodiment, the value OxABCl is used as an Ethernet type for ABC.
Referring to Figure SB, the encapsulation of an ABC frame inside an Ethernet frame 50 is shown. The E-type field 56 is set to OxABCl to specify that the data field 58 is a ABC frame made of an ABC header 60 and a ABC payload 62 (the payload is not present if the ABC frame is a Supervisory or an Uimwnbered frame).
Referring to Figure SC, the encapsulation of an ABC frame inside a HARD
flame inside an Ethernet frame 50 is shown. The E-type 56(a) is set to OxABCO
to indicate that the Ethernet Data field 58 is an HARD frame. The HARD header 64 contains an Ethernet type field 56(b) which has been set to OxABCl to indicate that the HARD payload 66 is an ABC frame made of an ABC header 60 and a ABC
payload 62.
Referring to Figure 6A, the encapsulation of an ABC frame inside an IP
datagram is shown. The datagram 70 includes an IP header 72, an ABC protocol header 74, and a Generic Routing Encapsulation (GRE) header 76 between the IP
and ABC protocol headers. Since it is not possible to define an IP Protocol Type for ABC, the GRE header 76 has been included to indicate that a particular IP datagram is carrying an ABC frame. The GRE header 76 includes an Ethernet Protocol Type field 84 for holding the type of protocol to be carried inside an IP datagram.
In this case, since the ABC protocol is being carried, the Ethernet Protocol Type field 84 is set to OxABCl.
RefeiTing to Figure 6B, the encapsulation of an ABC frame inside a HARD
frame inside an IP datagram is shov~m. The IP datagram 90 includes an IP
header 72, an ABC protocol header 74, a GRE header 76, and a HARD header 92. The HARD
header includes a Sequence Number field 94, SoL~rce ID field 96, a Protocol Type field 98. In this case, the Ethernet Protocol Type field 84 of the GRE header 76 is set to OxABCO to indicate that an HARD paclcet is encapsulated in the IP datagram.
In turn, the Protocol Type field 98 of the HARD header 92 is set to OxABCl to indicate that an ABC frame 74 is encapsulated in the HARD packet. For more information on HARD, see the aforementioned co-pending application Apparatus and Method for a High Availability Data Network Using Replicated Delivery", incorporated by reference herein.
ABC Protocol Operation The ABC protocol operation is exactly the same as the LLC-Type 2 protocol described in Section XX of Pact 2; Logical Linlc Control, ANSI/IEEE Std.
802.2, 1998 Edition.
Flow Control Flow control is an end-to-end mechanism whose purpose is preventing packet drops at a receiving node due to buffer over-flow conditions caused by a fast transmitting node. ABC has two build-in flow control mechanisms: the sliding window typical of LLC-2 and a "stop-and-go" mechanism based on the Receiver Ready (RR) and Receiver Not Ready (RNR) Supervisory frames. The sliding window mechanism alone would often be insufficient in controlling the flow rate of a transmitting node. In fact, if frame aclazowledgments are generated as soon as information frames are received, the transmitter is informed that more buffer space is available at the receiver, but actually it is not, at least until the application at the receiving node has removed data from the buffer. This situation could cause an over-flow condition at the buffer of the receiving node because the sending node will be allowed to send more Information frames as soon as it receives the aclaiowledgments.
To avoid the aforementioned problem, the sliding window of the ABC
protocol is integrated with the stop-and-go mechanism. Referring to Figure 7, a diagram 120 illustrating the stop-and-go mechanism used by the ABC protocol is ShOWIl. The diagram 120 shows along the x-axis the buffer capacity, denoted by "C", a low level threshold tL and a high level threshold tH. The RNR and RR frames are shoran along the y-axis of the diagram. When the buffer level is below t~, there is plenty of buffer space available and no flow control is exeuted. As the usage of the increases, eventually the tI-I tlueshold is exceeded. When this occurs, , a RNR
Supervisory frame is issued to the transmitting node to stop it from transmitting. The tIi threshold is set in accordance with one embodiment sufficiently below the buffer capacity C in order to preserve some buffer space for the packets potentially in transit after the RNR Supervisory frame is issued. As the consuming application at the receiving node empties the buffer, eventually the level of the buffer usage will fall below the tL threshold. At this point, a RR frame is issued to the transmitting node and the transmission of paclcets resumes. The diagram 120 thus defines a hysteresis cycle governed by the thresholds tI-~ and tL. This cycle prevents the system from oscillating between a transmit and quiet state, which would add significantly to the global overhead on the network due to the frequent transmission of RNR and RR
Supervisory frames.
In another embodiment, the stop-and-go mechanism described above can be avoided provided that a simple change to the ABC protocol operation (as defined by the LLC-Type 2 operations) is made. The change consists in generating the acknowledgment frames only when the corresponding Information frames are removed from the buffer of the receiving node by the consuming applicationupper layer protocol. In this way the availability of buffer space is amlounced to the transmitter only when new space is actually made available.
Congestion Control When multiple traffic flows share the same link there is always a chance of congestion. Congestion happens when the sum of the bandwidths of each flow exceeds the capacity of the liuc. When congestion occurs, the buffer behind the liuc begins to fill up. Eventually, an overflow condition occurs as the capacity of the buffer is exceeded, resulting in the dropping of incoming packets. Packet drops are to be avoided as much as possible with the ABC protocol. Since ABC exploits a go-baclc-N retransmission scheme (i.e., all the frames transmitted after a frame whose aclalowledgment is not received are retransmitted along with the missing packet), potentially every dropped frame can result in a full window of data being retransmitted, thus, exacerbating the congestion problem. To deal with congestion, the LLC-Type 2 protocol has been provided with a congestion control mecha~iism (see Amzex G of the LLC-Type 2 specification), but such a mechanism seems to be both inadequate and inefficient. Therefore, the ABC protocol replaces the LLC-Type 2 mechanism with a more effective and efficient mechanism derived from TCP
protocol congestion control techniques.
Each ABC transmitting node maintains per each connection foLU state variables: the current send window "snd wnd", the congestion window "cwnd", the slow start threshold "ssthresh", and the aclcnowledgment frame count "aclc cnt". The send window is used, in association with the stop-and-go technique described above in relation to Figure 7, to implement and end-to-end flow control mechanism.
The purpose of the send window is to keep track of the number of frames that the receiver is able to accept at any given time. In contrast, the congestion window defines the maximum number of information frames a sender is allowed to send at any give time.
Before transmitting any packet, an ABC transmitting node checks the two windows and selects the smaller of the two. The smaller value is the ulunber of information frames that can be transmitted at that time.
Referring Figure 8, an ABC congestion window diagram is shown. The y-axis represents the congestion window which is initialized at one (1). The x-axis represents time expressed in units of Round Trip Time (RTT). With each received acknowledgment frame, the congestion window cwnd is incremented by one. This implies that, under normal circLUnstances the congestion window grows over time as a power of two. This is clearly ShoWll 111 Figure 8, where, at every RTT the congestion window is incremented by one (1), two (2), four (4), eight (8) and sixteen (16). This process, referred to as slow staot continues until the congestion window reaches the slow start threshold ssthresh, whose value has initially been set to the value of the send window. During the slow start phase, a transmitting node will quickly reach a state where the transmission of information frames is only governed by the end-to-end flow control, i.e., either by the send window or by the stop-and-go mechanism described earlier.
However, when a congestion condition is inferred by the sender upon receiving a REJ frame indicating that the receiver is missing one frame, the congestion window is instantly "shrm~lc" to its initial value (one), allowing the sender to send only one information flame. The slow start threshold is set to one half of the current window (which is the minimum of the congestion and the send window) but never smaller than two (in this case sstllresh2 = 8). Thereafter, the congestion window is incremented again as acknowledgment frames are again received according to the slow start phase. However, this time the slow start tlueshold is only 8 frames, therefore the slow start phase lasts for only three RTTs. At this point the congestion avoidance phase starts, during which the congestion window is incremented by one for every RTT. This implies that during the congestion avoidance phase the congestion window increases linearly over time, as clearly shown in Figure 8.
To achieve this, during the congestion avoidance phase, the number of aclalowledgment frames received is counted by the variable aclc cnt and, when it becomes equal to the congestion window, it means that one RTT has elapsed. The congestion window is incremented by one and the aclc cnt is reset to zero, to count the aclaiowledgments frames received during the next RTT. This process continues Until either the congestion window becomes equal to the send window, or another congestion condition is detected.
In order to prevent multiple transmitters from synchronizing and start retransmission all at the same time (condition wluch is very likely to happen within a storage system such as that described in the above-identified co-pending application entitled "A Scalable Network Attached Storage System" where all transmitters observed almost the same RTT), a retransmission timer is used. As soon as congestion is detected, the retransmission timer is stauted and.the transmitting node starts the retransmission procedure only after this timer has expired. The value of this timer is a random number picked in the range [0,2N x RTT], where RTT is the typical round trip time of a frame in the system, and N is the number of retransmission attempts for an information frame. The initial value for N is zero and is incremented every time a REJ Supervisory frame for the same sequence number is received.
After a successful retransmission, or after receiving a REJ frame for another sequence number, N is cleared. This is an exponential retransmission back-off mechanism similar to one used by Ethernet, which is lazown to be effective in avoiding the syncluonization of multiple transmitters.
The embodiments of the present invention described above are to be considered as illustrative and not restrictive. The invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
achieves reliability by means of an acknowledge-and-retransmission mechanism.
Generally speaking, a receiving TCP entity acknowledges every packet it receives from the transmitting TCP entity. When one of such acknowledgments is not received within a certain period of time (called the Retf°ansmissioh Tiyoeout), the transmitting TCP entity assumes that the corresponding paclcet has been lost in the network and retransmits it. This retransmission mechanism has been improved over the years in order to make it more efficient. For example, an algoritlun called Fast Reti°ansJ~zit has been added to TCP to trigger a retransmission of a missing packet well before a the retransmission timeout occurs. Also, the retransmission timeout has been made adaptive to the network size and load by adding an estimator of the round-trip-time, i.e., the time it talces for a TCP packet to reach its destination plus the time necessary for its acknowledgment to come back.
The TCP protocol also provides a flow control function, which is defined as the ability of the receiving node to control the rate at which paclcets are transmitted to it to prevent the overflow of its input buffer. To this end, TCP employs a flow control mechanism called sliding wiv~dow. A receiving TCP entity continuously informs the transmitting TCP entity about the amount of free input buffer (the so called offe~~d wiyadow). When this amount drops to zero, the transmitting TCP entity refrains from transmitting any further data to the receiving entity until new space becomes available in the input buffer.
Another important capability built into TCP is the congestion control function.
It has already been noted that when a transmitting TCP entity does not receive an acknowledgment, it assumes the packet was dropped by the networlc. There are many reasons for which the network can drop a packet, e.g., data corruption, faulty lines and/or networlc, buffer congestion, etc. Of all those reasons, congestion is the by far the most common, especially in large networks such as the Internet. Therefore, when an aclalowledge goes missing, TCP not only assumes that a packet was dropped, it also assumes that the reason for this drop is networlc congestion. A number of algoritlnns such as Slow Start and Fast Recovery have been embedded into TCP
in order to deal with congestion. The pwpose of such algoritlnns is to tluottle doom the transmission rate in different ways depending on the severity of the congestion detected in the network.
One problem with TCP is that the three functions mentioned above, i.e., reliable delivery, flow control, and congestion control as well as other functionality make it an extremely complex protocol from the implementation standpoint. As a result, most network nodes typically implement TCP as a software module embedded in the operating system. Clearly this solution is not particularly fast and also consumes CPU cycles that could be used to run user applications. There are also a few TCP implementations that rely on micro-controller chips and special software (micro-code) to offload the system CPU from the task of running TCP. This solution is faster and more efficient than the previous one, but is still inadequate for high speed (i.e., mufti gigabit per second) networks.
A fast, lightweight, reliable, packet-based protocol that operates independent of the type underlying protocol layer is therefore needed.
SUMMARY OF THE INVENTION
To achieve the foregoing, and in accordance with the propose of the present invention, a fast, lightweight, reliable, packet-based transport protocol that operates independent of the type of the underlying protocols is disclosed. More specifically,.
this protocol, hereafter referred to as the ABC protocol, can be carried by protocols such as but not limited to IEEE 802.3, Ethernet, Ethernet II, HARD or IP. The ABC
protocol defines at least tluee different types of frames including Information frames, Supervisory frames, and Unnumbered frames. In various embodiments of the invention, the Information, Supervisory, and Unnumbered frames include Destination Service Access Point (DSAP) and Source Service Access Point (SSAP) fields which are sufficiently large to support the various applications that may be used on the network. The Information frames, Supervisory frames, and Unnumbered frames also have the ability to support urgent data delivery and certain memory management functions. The ABC protocol is ftirther capable of support the multiplexing of higher layer protocols so that multiple higher layer applications may share the same comlection. Finally, the ABC protocol of the present invention supports both flow control and congestion control, to help reduce the incidence of lost or dropped packets at a receiving node or over the networlc.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure lA is the header of an Information frame used by the ABC protocol of the present invention.
Figure 1B is the format of the Control field of the Information frame header of Figure lA according to the present invention.
Figures 1 C is the format of the Flags field of the Information frame header of Figure lA according to the present invention.
Figure 2A illustrates the header of a Supervisory frame of the ABC protocol of the present invention.
Figure 2B is the format of the Control field of the Supervisory frame header of Figure 2A according to the present invention.
Figure 3 illustrates the header of an UnnLUnbered frame used by the ABC
protocol of the present invention.
Figure 3B is the format of the Control field of the Unnumbered frame header of Figure 3A according to the present invention.
Figure 3C is the header of a XID frame used by the ABC protocol according to the present invention.
Figure 4 is illustrates the ABC protocol of the present invention layered on top of r a MAC layer, IP layer of a HARD layer according to various embodiments of the present invention.
Figure SA illustrates an Ethernet II frame format.
Figure SB illustrates the encapsulation of an ABC packet inside of an Ethernet II frame according to the present invention.
Figure SC illustrates the encapsulation of an ABC packet inside an HARD
packet, in turn, inside an Ethernet II frame according to the present invention.
Figure 6A illustrates the encapsulation of an ABC packet inside an IP
datagram according to the present invention.
Figure 6B illustrates the encapsulation of an ABC paclcet inside an HARD
packet, in turn inside an IP datagram according to the present invention.
Figure 7 is a diagram illustrating the cycle of the stop-and go flow control mechanism used by the ABC protocol of the present invention.
Figure 8 is a diagram illustrating an ABG protocol congestion window evolution over time according to the present invention is shown.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The fast, lightweight, reliable, packet-based transport protocol of the present invention, hereafter referred to as the ABC protocol, is a modification of the Logical Lint Control - Part 2 (LLC-Type 2) protocol. More specifically, the ABG
protocol of the present invention uses the state machine of the LLC Type 2 protocol without substantial modifications while modifying and extending certain aspects of LLC
Type 2, as described here. For more information on the LLC -Type 2, see Part 2;
logic Link Control, ANSI/IEEE Std. 802.2, 1998 Edition, incorporated in its entirety herein for all purposes.
Modifications to LLC-Type 2 The ABC protocol of the present invention modifies the LLC Type 2 protocol in tluee basic areas: addressing, flow and congestion control, and Out-of Band signaling.
Each LLC-Type 2 Protocol Data Unit (PDU) contains two address fields, the Destination Service Access Point (DSAP) and the Sol~rce Service Address Point (SSAP). Each of these fields is eight bits wide and includes seven bits of actual address information. The least significant bit (LSB) in the DSAP field is used to identify the DSAP address as either an individual or a group address. The least significant eighth bit in the SSAP field is used to identify the LLC PDU as either a command or a response, and is therefore sometimes referred to as command/response identifier bit. The ABC protocol of the present invention extends the LLC-Type addressing capabilities by having sixteen bit wide DSAP and SSAP fields. The semantic of the LSB for both fields remains the same as LLC-Type 2. The remaining fifteen bits, however, are now used for addressing pwposes with the DSAP and SSAP
fields respectively.
LLC-Type 2 relies on both the DSAP and SSAP fields in the LLC Type 2 header and the MAC source and destination addresses to identify a comzection.
Since the ABC protocol of the present invention operates independently of the underlying physical layer and can be used with almost any type of networking media, the semantics of the DSAP and SSAP fields have been slightly changed in such a way that connections are uniquely identified only by the DSAP and SSAP addresses.
A
media access control or MAC address is not needed with the present invention.
This modification enables the ABC protocol of the present invention to be very flexible and allows it to run on any underlying layer such as IP or Ethernet without any maj or modifications.
LLC Type 2 flow control is mainly intended for point-to-point lincs, while in ABC flow control is modified in order to work with an arbitrary munber of lines between a pair of ABC nodes. As far as congestion control is concerned, the most currently available LLC-Type2 specification includes an Annex, i.e., Aimex C, which defines optional congestion control techniques for bridged LANs. The congestion control technique therein described seems to be inadequate to deal with severe congestion and penalizes substantially a comlection from the bandwidth standpoint, especially if a network is large and the Round Trip Time (RTT) is considerable. ABC
replaces the Annex C technique with a congestion control mechanism very similar to the one employed by the TCP protocol, which is widely lmown to be both effective and efficient. Flow control and congestion control are described in detail later in this application.
Finally, ABC requires the mandatory implementation of the XID and TEST
frames for out-of band signaling, as specified in the LLC-Type2 specification.
Extensions to LLC-Type Z
The ABC protocol extends the LLC-Type 2 protocol, by adding some extra functionality, in the following areas: memory management and segmentation, support for iugent data, and higher layer/application multiplexing.
As far as memory management is concerned, ABC allows a transmitting entity to signal a receiving entity that it needs to allocate a new buffer for data, tluough the NEW BUFFER bit, or that a data unit has been completed and it can be delivered to the upper layer, through the END OF DATA bit.
ABC supports the delivery of urgent data to the destination ABC entity. When such an entity receives an Information frame marked urgent, the data contained in this frame is not buffered but immediately delivered to the upper layer protocol.
Finally, ABC allows multiple applications to share the same connection (i.e., having their packets sent using the same DSAP/SSAP pair. Application multiplexing is implemented in a way similar to TCP (Transmission Control Protocol) or UDP
(User Datagram Protocol), i.e., by means of two 16-bit fields called Source Port and Destination Port.
ABC Frame Types The ABC protocol of the present invention uses three different types of frames, similar to LLC-Type 2. The three types include Information frames, Supervisory frames and Ummmbered frames.
Referring to Figure lA, the header of an Information frame used by the ABC
protocol of the present invention is shown. The Information frame header 10 includes a total of six fields, each sixteen bits wide. The six fields include a DSAP
field, an SSAP field, a control field 12, a Flags field 14, and Source and Destination port fields respectively. The DSAP field identifies an ABC protocol connection at the destination node. The least significant bit is the Individual/Group bit as defined by the LLC-Type 2 specification. The remaining fifteen bits are used to identify the comiection on the destination node. The SSAP field identifies the ABC protocol connection on the source node. The least significant bit is the Command/Response bit as defined by the LLC-Type 2 specification. The remaining fifteen bits are used to define the comiection on the source code. Since fifteen bits in either the DSAP or the SSAP
fields are used as connection identifiers, a maximwn of 215=32768 connections can be active at an ABC node. In another embodiment of the present invention, the concatenation of the upper fifteen bits of the DSAP and the upper fifteen bits of the SSAP can be used as a comlection identifier to increase the maximum n Lunber of active connections, if needed. The DSAP and SSAP, fields are essentially the same as those defined by the LCC-Type 2 specification, except they are sixteen and not eight bits wide. The source Port field identifies the source application, while the Destination pout field identifies the destination application.
As illustrated in Figure 1B, the control field of an Information Frame is used to hold sequence numbers and control information. The control field 12 has its most significant bit always set to zero (0) according to the preferred embodiment.
The next seven bits represent the send sequence number N(S) of the sender. The first bit of the second byte is the Poll/Final bit as defined by the LLG-Type 2 specification.
The remaining seven bits represent the receive sequence number N(R) of the sender.
In Figure 1C, the various flags of the Flag field 14 are illustrated. These flags include from the most significant to the least significant bits, two bits to indicate the protocol version number (VERS), three memory management flags (HM, NB and EOD), and the urgent data flag (URG). The HM flag indicates if Hardware Memory management is supported or not. If this flag is set, the NB and EOD flags are considered valid. The New Buffer (NB) flag indicates that a new buffer must be allocated at the receiver to hold the data of the present and subsequent Information frames. The End of Data (EOD) flag indicates that this frame carries the last fragment of an upper layer data unit and, therefore, this data unit can be delivered and the buffer returned to the free pool. Finally, the urgent data flag (URG), when set, informs the receiving ABC entity that the data contained in this frame is urgent and must be delivered to the upper layer without being buffered. The remaining "Reserved" bits are available for the addition of new flags as needed.
Referring to Figure 2A, the format of the header of a Supervisory frame of the ABC protocol of the present invention is shown. The Supervisory frame header includes three fields, DSAP, SSAP and a Control field 22. The format of the header of a Supervisory frame 20 is essentially the same as the Supervisory frame of the LLC-Type 2 protocol, except the DSAP and SSAP fields are sixteen and not eight bits wide.
In Figure 2B, the Control field 22 is shown. The two most significant bits of the Control field 22 are set to, according to one embodiment, "10" for every Supervisory frame header 20. The next two bits (SS) identify the Supervisory frame type. The Supervisory flame types include Receiver Ready (RR) [SS=00], Receiver Not Ready (RNR) [SS=10], and Reject (RJT) [SS=O1]. The next four bits are unused while the Poll/Final bit is at the same bit position as the Information frame.
The seven least significant bits are used to represent the receive sequence number N(R) of the sender .
Referring to Figure 3A, the header of an Ummmbered frame used by the ABC
protocol of the present invention is shovm. The Ummunbered frame header 30 is similar to the Supervisory frame header 20, except the control field 32 is only eight bits wide. As illustrated in Figure 3B, the first two most significant bits are always set to "11" according to one embodiment, the fifth bit is the Poll/Find (P/F) bit, and all the remaining bits (M) specify the Ummmbered frame type. Table I below defines the ummmbered frames that are implemented with the ABC protocol of the present invention.
Table I
Command/Response Description MMMMM
SABME Command Set Asynchronous 11110 ~
Balanced Mode Extended:
used to initiate a comlection DISC Cormnand Disconnect: used 00010 to terminate a comiection UA Response Urmumbered 00110 Acknowledgement:
used to respond to SABME
or DISC Command DM Response Disconnect Mode: 11000 used to respond to non-SABME
frames received when a comlection is not yet started.
FRMR Response Frame Reject: used 10001 to Resume from Error Conditions.
XID Command/Response ~ Exchange Identification: ~ 11101 used to negotiate the window size Test Command/Response ~ Test: used to verify the ~ 00111 status of a remote ABC
station The XID Command/Response is used with the ABC protocol of the present invention only to communicate the receiver window size (RW). It therefore uses a simplified format compared to the LLC Type-2 version. With the LLC Type-2 version, every LLC protocol class supported by the sending entity must be listed.
Figure 3C illustrates the XID frame of the present invention. Following the Control Feld 32, there is an eight bit information field 34. The most significant bit is set to zero. The remaining seven bits convey the window size of the receiving entity (RW).
Encapsulation The ABC protocol of the present invention operates independent of the type of mderlying protocol. The ABC protocol can be used on top of Ethernet, Ethernet II, IP
or HARD. For a more detailed explanation of HARD, see the aforementioned U.S.
Application Serial Number 101313,745 (attorney docket number ANDIP023) filed on December 6, 2002 entitled "Apparatus and Method for a High Availability Data Network Using Replicated Delivery" by Gai Silvano et. al.
Referring to Figure 4, the ABC protocol 40 of the present invention is shown deployed either over an Ethernet MAC layer or an IP layer with or without HARD
in both cases. The encapsulation of the ABC protocol 40 of the present invention inside Ethernet/Ethernet II frames and IP datagrams, optionally using the high availability features of the HARD protocol are described below. The chief adva~ltage of encapsulating the ABC protocol inside IP datagrams is the ability to malce the ABC
protocol mutable. A disadvantage is that the hardware implementing the ABC
protocol may have to deal with IP fragmentation.
Referring to Figure SA, an Ethernet (or Ethernet II) frame format is shown.
The frame 50 includes a Destination Address (DA) field 52, a Source Address (SA) field 54, an Ethernet Type (Etype) field 56, a data field 58, and a Frame Checlc Sequence (FCS) field 59. In order to encapsulate ABC frames inside Ethernet frames, a new Ethernet type is needed to identify the ABC protocol data unit carried as an Ethernet Data field 50. In one embodiment, the value OxABCl is used as an Ethernet type for ABC.
Referring to Figure SB, the encapsulation of an ABC frame inside an Ethernet frame 50 is shown. The E-type field 56 is set to OxABCl to specify that the data field 58 is a ABC frame made of an ABC header 60 and a ABC payload 62 (the payload is not present if the ABC frame is a Supervisory or an Uimwnbered frame).
Referring to Figure SC, the encapsulation of an ABC frame inside a HARD
flame inside an Ethernet frame 50 is shown. The E-type 56(a) is set to OxABCO
to indicate that the Ethernet Data field 58 is an HARD frame. The HARD header 64 contains an Ethernet type field 56(b) which has been set to OxABCl to indicate that the HARD payload 66 is an ABC frame made of an ABC header 60 and a ABC
payload 62.
Referring to Figure 6A, the encapsulation of an ABC frame inside an IP
datagram is shown. The datagram 70 includes an IP header 72, an ABC protocol header 74, and a Generic Routing Encapsulation (GRE) header 76 between the IP
and ABC protocol headers. Since it is not possible to define an IP Protocol Type for ABC, the GRE header 76 has been included to indicate that a particular IP datagram is carrying an ABC frame. The GRE header 76 includes an Ethernet Protocol Type field 84 for holding the type of protocol to be carried inside an IP datagram.
In this case, since the ABC protocol is being carried, the Ethernet Protocol Type field 84 is set to OxABCl.
RefeiTing to Figure 6B, the encapsulation of an ABC frame inside a HARD
frame inside an IP datagram is shov~m. The IP datagram 90 includes an IP
header 72, an ABC protocol header 74, a GRE header 76, and a HARD header 92. The HARD
header includes a Sequence Number field 94, SoL~rce ID field 96, a Protocol Type field 98. In this case, the Ethernet Protocol Type field 84 of the GRE header 76 is set to OxABCO to indicate that an HARD paclcet is encapsulated in the IP datagram.
In turn, the Protocol Type field 98 of the HARD header 92 is set to OxABCl to indicate that an ABC frame 74 is encapsulated in the HARD packet. For more information on HARD, see the aforementioned co-pending application Apparatus and Method for a High Availability Data Network Using Replicated Delivery", incorporated by reference herein.
ABC Protocol Operation The ABC protocol operation is exactly the same as the LLC-Type 2 protocol described in Section XX of Pact 2; Logical Linlc Control, ANSI/IEEE Std.
802.2, 1998 Edition.
Flow Control Flow control is an end-to-end mechanism whose purpose is preventing packet drops at a receiving node due to buffer over-flow conditions caused by a fast transmitting node. ABC has two build-in flow control mechanisms: the sliding window typical of LLC-2 and a "stop-and-go" mechanism based on the Receiver Ready (RR) and Receiver Not Ready (RNR) Supervisory frames. The sliding window mechanism alone would often be insufficient in controlling the flow rate of a transmitting node. In fact, if frame aclazowledgments are generated as soon as information frames are received, the transmitter is informed that more buffer space is available at the receiver, but actually it is not, at least until the application at the receiving node has removed data from the buffer. This situation could cause an over-flow condition at the buffer of the receiving node because the sending node will be allowed to send more Information frames as soon as it receives the aclaiowledgments.
To avoid the aforementioned problem, the sliding window of the ABC
protocol is integrated with the stop-and-go mechanism. Referring to Figure 7, a diagram 120 illustrating the stop-and-go mechanism used by the ABC protocol is ShOWIl. The diagram 120 shows along the x-axis the buffer capacity, denoted by "C", a low level threshold tL and a high level threshold tH. The RNR and RR frames are shoran along the y-axis of the diagram. When the buffer level is below t~, there is plenty of buffer space available and no flow control is exeuted. As the usage of the increases, eventually the tI-I tlueshold is exceeded. When this occurs, , a RNR
Supervisory frame is issued to the transmitting node to stop it from transmitting. The tIi threshold is set in accordance with one embodiment sufficiently below the buffer capacity C in order to preserve some buffer space for the packets potentially in transit after the RNR Supervisory frame is issued. As the consuming application at the receiving node empties the buffer, eventually the level of the buffer usage will fall below the tL threshold. At this point, a RR frame is issued to the transmitting node and the transmission of paclcets resumes. The diagram 120 thus defines a hysteresis cycle governed by the thresholds tI-~ and tL. This cycle prevents the system from oscillating between a transmit and quiet state, which would add significantly to the global overhead on the network due to the frequent transmission of RNR and RR
Supervisory frames.
In another embodiment, the stop-and-go mechanism described above can be avoided provided that a simple change to the ABC protocol operation (as defined by the LLC-Type 2 operations) is made. The change consists in generating the acknowledgment frames only when the corresponding Information frames are removed from the buffer of the receiving node by the consuming applicationupper layer protocol. In this way the availability of buffer space is amlounced to the transmitter only when new space is actually made available.
Congestion Control When multiple traffic flows share the same link there is always a chance of congestion. Congestion happens when the sum of the bandwidths of each flow exceeds the capacity of the liuc. When congestion occurs, the buffer behind the liuc begins to fill up. Eventually, an overflow condition occurs as the capacity of the buffer is exceeded, resulting in the dropping of incoming packets. Packet drops are to be avoided as much as possible with the ABC protocol. Since ABC exploits a go-baclc-N retransmission scheme (i.e., all the frames transmitted after a frame whose aclalowledgment is not received are retransmitted along with the missing packet), potentially every dropped frame can result in a full window of data being retransmitted, thus, exacerbating the congestion problem. To deal with congestion, the LLC-Type 2 protocol has been provided with a congestion control mecha~iism (see Amzex G of the LLC-Type 2 specification), but such a mechanism seems to be both inadequate and inefficient. Therefore, the ABC protocol replaces the LLC-Type 2 mechanism with a more effective and efficient mechanism derived from TCP
protocol congestion control techniques.
Each ABC transmitting node maintains per each connection foLU state variables: the current send window "snd wnd", the congestion window "cwnd", the slow start threshold "ssthresh", and the aclcnowledgment frame count "aclc cnt". The send window is used, in association with the stop-and-go technique described above in relation to Figure 7, to implement and end-to-end flow control mechanism.
The purpose of the send window is to keep track of the number of frames that the receiver is able to accept at any given time. In contrast, the congestion window defines the maximum number of information frames a sender is allowed to send at any give time.
Before transmitting any packet, an ABC transmitting node checks the two windows and selects the smaller of the two. The smaller value is the ulunber of information frames that can be transmitted at that time.
Referring Figure 8, an ABC congestion window diagram is shown. The y-axis represents the congestion window which is initialized at one (1). The x-axis represents time expressed in units of Round Trip Time (RTT). With each received acknowledgment frame, the congestion window cwnd is incremented by one. This implies that, under normal circLUnstances the congestion window grows over time as a power of two. This is clearly ShoWll 111 Figure 8, where, at every RTT the congestion window is incremented by one (1), two (2), four (4), eight (8) and sixteen (16). This process, referred to as slow staot continues until the congestion window reaches the slow start threshold ssthresh, whose value has initially been set to the value of the send window. During the slow start phase, a transmitting node will quickly reach a state where the transmission of information frames is only governed by the end-to-end flow control, i.e., either by the send window or by the stop-and-go mechanism described earlier.
However, when a congestion condition is inferred by the sender upon receiving a REJ frame indicating that the receiver is missing one frame, the congestion window is instantly "shrm~lc" to its initial value (one), allowing the sender to send only one information flame. The slow start threshold is set to one half of the current window (which is the minimum of the congestion and the send window) but never smaller than two (in this case sstllresh2 = 8). Thereafter, the congestion window is incremented again as acknowledgment frames are again received according to the slow start phase. However, this time the slow start tlueshold is only 8 frames, therefore the slow start phase lasts for only three RTTs. At this point the congestion avoidance phase starts, during which the congestion window is incremented by one for every RTT. This implies that during the congestion avoidance phase the congestion window increases linearly over time, as clearly shown in Figure 8.
To achieve this, during the congestion avoidance phase, the number of aclalowledgment frames received is counted by the variable aclc cnt and, when it becomes equal to the congestion window, it means that one RTT has elapsed. The congestion window is incremented by one and the aclc cnt is reset to zero, to count the aclaiowledgments frames received during the next RTT. This process continues Until either the congestion window becomes equal to the send window, or another congestion condition is detected.
In order to prevent multiple transmitters from synchronizing and start retransmission all at the same time (condition wluch is very likely to happen within a storage system such as that described in the above-identified co-pending application entitled "A Scalable Network Attached Storage System" where all transmitters observed almost the same RTT), a retransmission timer is used. As soon as congestion is detected, the retransmission timer is stauted and.the transmitting node starts the retransmission procedure only after this timer has expired. The value of this timer is a random number picked in the range [0,2N x RTT], where RTT is the typical round trip time of a frame in the system, and N is the number of retransmission attempts for an information frame. The initial value for N is zero and is incremented every time a REJ Supervisory frame for the same sequence number is received.
After a successful retransmission, or after receiving a REJ frame for another sequence number, N is cleared. This is an exponential retransmission back-off mechanism similar to one used by Ethernet, which is lazown to be effective in avoiding the syncluonization of multiple transmitters.
The embodiments of the present invention described above are to be considered as illustrative and not restrictive. The invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
Claims (27)
1. An apparatus comprising:
a packet based transport protocol for use in data networks that operates independent over the underlying physical layer used by the network.
a packet based transport protocol for use in data networks that operates independent over the underlying physical layer used by the network.
2. The apparatus of claim 1, wherein the protocol defines at least three different types of frames including Information frames, Supervisory frames, and Unnumbered frames.
3. The apparatus of claim 1, wherein the Information frame header contains the following fields:
a DSAP field configured to identify the protocol connection of a destination node in the network, a SSAP field configured to identify the protocol connection of a source node in the network;
a control field configured to carry sequence numbers and control information;
a flags field configured to maintain one or more flags;
a source port configured to identify a source application; and a destination port configured to identify a destination application.
a DSAP field configured to identify the protocol connection of a destination node in the network, a SSAP field configured to identify the protocol connection of a source node in the network;
a control field configured to carry sequence numbers and control information;
a flags field configured to maintain one or more flags;
a source port configured to identify a source application; and a destination port configured to identify a destination application.
4. The apparatus of claim 3, wherein the DSAP and SSAP fields are each sixteen bits long with one bit of both fields used for identifying either an individual or a group address and the remaining fifteen bits used for addressing respectively.
5. The apparatus of claim 3, wherein the control field of the Information frame has one bit set to indicate that it is an Information frame, a first set of bits used to identify the send sequence number of the sender, a second set of bits used to identify the receive sequence number of the sender, and a Poll/Final bit.
6. The apparatus of claim 3, wherein the flags field includes flags for one or more of the following: a version field, memory management fields, and an urgent field.
7. The apparatus of claim 2, wherein the Supervisory frame contain one or more of the following types of fields:
a DSAP field configured to identify the protocol connection of a destination node in the network;
a SSAP field configured to identify the protocol connection of a source node in the network; and a control field configured to carry sequence numbers and control information.
a DSAP field configured to identify the protocol connection of a destination node in the network;
a SSAP field configured to identify the protocol connection of a source node in the network; and a control field configured to carry sequence numbers and control information.
8. The apparatus of claim 7, wherein the DSAP and SSAP fields are each sixteen bits long with one bit of both fields used for identifying either an individual or a group address and the remaining fifteen bits used for addressing respectively.
9 The apparatus of claim 8, wherein the control field of the Supervisory frame has its two bits set to indicate that the frame is a Supervisory frame, a first set of bits used to identify a Supervisory frame type, a second set of bits used to identify the receive sequence number of the sender, and a Poll/Final bit.
The apparatus of claim 2, wherein the Unnumbered frame contain one or more of the following types of fields:
a DSAP field configured to identify the protocol connection of a destination node in the network;
a SSAP field configured to identify the protocol connection of a source node in the network; and a control field configured to carry control information.
a DSAP field configured to identify the protocol connection of a destination node in the network;
a SSAP field configured to identify the protocol connection of a source node in the network; and a control field configured to carry control information.
11 The apparatus of claim 10, wherein the DSAP and SSAP fields are each sixteen bits long with the one bit of both fields used for identifying either an individual or a group address and the remaining fifteen bits used for addressing respectively.
12 The apparatus of claim 10, wherein the control field is configured to carry one or more of the following control commands or responses:
a Set Asynchronous Balance Mode Extended (SABME) command;
a Disconnect (DISC) command to disconnect a connection;
An Unnumbered Acknowledgement (UA) response to answer a SABME or DISC command;
a Disconnect Mode response to answer to a not SABME command when a connection has not yet started;
a Frame Reject (FRMR) response for resuming operation after an error condition;
an Exchange/Identification (XID) command/response to negotiate the window size of a receiving node in the network; and a TEST command/response to verify the status of a remote node in the network.
a Set Asynchronous Balance Mode Extended (SABME) command;
a Disconnect (DISC) command to disconnect a connection;
An Unnumbered Acknowledgement (UA) response to answer a SABME or DISC command;
a Disconnect Mode response to answer to a not SABME command when a connection has not yet started;
a Frame Reject (FRMR) response for resuming operation after an error condition;
an Exchange/Identification (XID) command/response to negotiate the window size of a receiving node in the network; and a TEST command/response to verify the status of a remote node in the network.
13 The apparatus of claim 12, wherein the format of the Exchange/Identification (XID) command/response includes a control field and a field used to define the window size of the receiving node.
14 The apparatus of claim 1, wherein the protocol is further configured to encapsulate directly on top of an Ethernet or Ethernet II frame, the encapsulated protocol frame over the Ethernet or Ethernet II frame including a destination address field, a source address field, a data field, an E-type field, and a protocol header field.
15. The apparatus of claim 1, wherein the protocol is further configured to encapsulate over HARD on top of an Ethernet or Ethernet II frame, the encapsulated protocol frames over HARD on top of the Ethernet or Ethernet II frame including a destination address field, a source address field, a data field, an E-type field, a HARD
field, and a protocol header field.
field, and a protocol header field.
16. The apparatus of claim 1, wherein the protocol is further configured to encapsulate over a Generic Routing Encapsulation protocol on top of the IP
protocol including a checksum present field C, a Reserved field, a Version field, and an Ethernet Protocol Type field indicating that the encapsulated protocol is ABC.
protocol including a checksum present field C, a Reserved field, a Version field, and an Ethernet Protocol Type field indicating that the encapsulated protocol is ABC.
17. The apparatus of claim 1, wherein the protocol is further configured to encapsulate over a HARD protocol over a Generic Routing Encapsulation protocol on top of the IP protocol, the HARD protocol including a sequence number field, a source ID field, and a protocol type field indicating that the encapsulated protocol is ABC, and the Generic Routing Encapsulation protocol including a checksum present field C, a Reserved field, a Version field, and an Ethernet Protocol Type field indicating that the encapsulated protocol is HARD.
18. The apparatus of claim 1, further comprising a flow control mechanism configured to control the flow of packets between a transmitting node and a receiving node in the network.
19. The apparatus of claim 1, wherein the flow control mechanism at the receiving node transmits a Receiver Not Ready command to the transmitting node when a receiving buffer for buffering received packets at the receiving node exceeds a first predetermined threshold and a Receiver Ready command when the number of buffered packets falls below a second predetermined threshold.
20. The apparatus of claim 1, further comprising a congestion control mechanism configured to prevent overflow conditions on a link in the network resulting in the possibility of packets being dropped.
21. The apparatus of claim 20, wherein the congestion control mechanism is configured to reduce the number of frames sent by a sending node when a reject message indicating that a receiving node did not receive a message is received by the receiving node.
22. The apparatus of claim 1, wherein the protocol is further configured to support the multiplexing of higher layers than the protocol so that multiple applications may share the same connection.
23. The apparatus of claim 1, wherein the underlying physical layer includes one of the following IEEE 802.3, Ethernet, Ethernet II, HARD, or IP.
24. The apparatus of claim 6, wherein the protocol supports the delivery of urgent data to the destination when the Urgent field of an Informational frame is set.
25. The apparatus of claim 6, wherein the protocol supports hardware memory management and segmentation when the memory management flags of an Informational frame are used.
26. The apparatus of claim 16 wherein the protocol can be routed over an IP
network.
network.
27. The apparatus of claim 21, wherein a back-off retransmission timer is used to avoid the synchronization of multiple transmitters where all transmitters observed almost the same Round Trip Time.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/313,305 | 2002-12-06 | ||
| US10/313,305 US7443845B2 (en) | 2002-12-06 | 2002-12-06 | Apparatus and method for a lightweight, reliable, packet-based transport protocol |
| PCT/US2003/037123 WO2004054207A2 (en) | 2002-12-06 | 2003-11-19 | Apparatus for implementing a lightweight, reliable, packet-based transport protocol |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2508748A1 true CA2508748A1 (en) | 2004-06-24 |
Family
ID=32468212
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002508748A Abandoned CA2508748A1 (en) | 2002-12-06 | 2003-11-19 | Apparatus for implementing a lightweight, reliable, packet-based transport protocol |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7443845B2 (en) |
| EP (1) | EP1568191A2 (en) |
| CN (1) | CN1729675A (en) |
| AU (1) | AU2003294395A1 (en) |
| CA (1) | CA2508748A1 (en) |
| WO (1) | WO2004054207A2 (en) |
Families Citing this family (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6934257B2 (en) * | 2001-04-04 | 2005-08-23 | Intel Corporation | Transferring transmission control protocol packets |
| US8270423B2 (en) * | 2003-07-29 | 2012-09-18 | Citrix Systems, Inc. | Systems and methods of using packet boundaries for reduction in timeout prevention |
| US7616638B2 (en) | 2003-07-29 | 2009-11-10 | Orbital Data Corporation | Wavefront detection and disambiguation of acknowledgments |
| US7475142B2 (en) * | 2002-12-06 | 2009-01-06 | Cisco Technology, Inc. | CIFS for scalable NAS architecture |
| US20040264452A1 (en) * | 2003-06-25 | 2004-12-30 | Gaurav Mittal | Apparatus, and associated method, for embedding control information into packet formatted data |
| US8437284B2 (en) | 2003-07-29 | 2013-05-07 | Citrix Systems, Inc. | Systems and methods for additional retransmissions of dropped packets |
| US7508763B2 (en) * | 2003-09-04 | 2009-03-24 | Hewlett-Packard Development Company, L.P. | Method to regulate traffic congestion in a network |
| US7525974B2 (en) * | 2003-11-10 | 2009-04-28 | Nortel Networks Limited | Method and apparatus for capability based addressing in a communications network |
| US7733856B2 (en) * | 2004-07-15 | 2010-06-08 | Alcatel-Lucent Usa Inc. | Obtaining path information related to a virtual private LAN services (VPLS) based network |
| DE102005025582B4 (en) * | 2005-06-01 | 2011-08-18 | Phoenix Contact GmbH & Co. KG, 32825 | Device and method for the combined transmission of input / output data in automation bus systems |
| US8189599B2 (en) * | 2005-08-23 | 2012-05-29 | Rpx Corporation | Omni-protocol engine for reconfigurable bit-stream processing in high-speed networks |
| US8260968B2 (en) * | 2006-01-23 | 2012-09-04 | Lantiq Deutschland Gmbh | Method and system for booting a software package on a network processor |
| US8260831B2 (en) * | 2006-03-31 | 2012-09-04 | Netapp, Inc. | System and method for implementing a flexible storage manager with threshold control |
| WO2008021372A2 (en) * | 2006-08-11 | 2008-02-21 | Slt Logic Llc | Enhanced ethernet protocol for shortened data frames within a constrained neighborhood based on unique id |
| US8189491B2 (en) * | 2007-07-10 | 2012-05-29 | Qualcomm Incorporated | Apparatus and method of generating and maintaining non-orthogonal connection identifications (CIDs) for wireless peer-to-peer networks |
| US8427951B2 (en) * | 2007-08-30 | 2013-04-23 | International Business Machines Corporation | Method, system, and apparatus for reliable data packet recovery in a link layer of a data center ethernet network |
| CN101197742B (en) * | 2007-12-21 | 2010-04-21 | 深圳市三旺通信技术有限公司 | System and method for transmitting additional data between equipments through Ethernet interface |
| US8019895B2 (en) | 2008-03-25 | 2011-09-13 | International Business Machines Corporation | Serial attached SCSI and serial ATA wide port tunnelling through a fibre channel connection |
| US8285900B2 (en) | 2009-02-17 | 2012-10-09 | The Board Of Regents Of The University Of Texas System | Method and apparatus for congestion-aware routing in a computer interconnection network |
| US10177934B1 (en) | 2009-09-04 | 2019-01-08 | Amazon Technologies, Inc. | Firmware updates inaccessible to guests |
| US8214653B1 (en) | 2009-09-04 | 2012-07-03 | Amazon Technologies, Inc. | Secured firmware updates |
| US8887144B1 (en) | 2009-09-04 | 2014-11-11 | Amazon Technologies, Inc. | Firmware updates during limited time period |
| US9565207B1 (en) | 2009-09-04 | 2017-02-07 | Amazon Technologies, Inc. | Firmware updates from an external channel |
| US8601170B1 (en) | 2009-09-08 | 2013-12-03 | Amazon Technologies, Inc. | Managing firmware update attempts |
| US8971538B1 (en) | 2009-09-08 | 2015-03-03 | Amazon Technologies, Inc. | Firmware validation from an external channel |
| US8959611B1 (en) | 2009-09-09 | 2015-02-17 | Amazon Technologies, Inc. | Secure packet management for bare metal access |
| US8300641B1 (en) | 2009-09-09 | 2012-10-30 | Amazon Technologies, Inc. | Leveraging physical network interface functionality for packet processing |
| US8381264B1 (en) | 2009-09-10 | 2013-02-19 | Amazon Technologies, Inc. | Managing hardware reboot and reset in shared environments |
| US9398490B2 (en) * | 2013-03-15 | 2016-07-19 | Trane International Inc. | Method of fragmenting a message in a network |
| CN103281794B (en) * | 2013-06-09 | 2017-02-01 | 重庆邮电大学 | Method of preferentially transmitting and scheduling emergency data in body area network |
| US9407547B2 (en) | 2013-12-13 | 2016-08-02 | Cisco Technology, Inc. | Fibre channel over ethernet (FCoE) over virtual port channel (vPC) |
| CN105320593B (en) * | 2014-07-29 | 2019-04-16 | 中兴通讯股份有限公司 | Multichannel frame random data authentication processing method and device |
| US10713202B2 (en) * | 2016-05-25 | 2020-07-14 | Samsung Electronics Co., Ltd. | Quality of service (QOS)-aware input/output (IO) management for peripheral component interconnect express (PCIE) storage system with reconfigurable multi-ports |
| CN108134721A (en) * | 2017-12-12 | 2018-06-08 | 天津津航计算技术研究所 | A kind of anti-adverse environment Ethernet LAN communication system |
| DE102019111881A1 (en) * | 2019-05-07 | 2020-11-12 | Infineon Technologies Ag | METHOD AND DEVICE FOR SENDING DATA ACCORDING TO A SIGNAL TIMING |
Family Cites Families (47)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2236930B (en) * | 1989-10-11 | 1994-03-23 | Plessey Co Plc | Method and apparatus for identifying valid cells in a redundant path combining unit of an asynchronous transfer mode switch |
| JPH03148940A (en) * | 1989-11-06 | 1991-06-25 | Hitachi Ltd | Mutual connection system for lan and isdn |
| US6374311B1 (en) | 1991-10-01 | 2002-04-16 | Intermec Ip Corp. | Communication network having a plurality of bridging nodes which transmit a beacon to terminal nodes in power saving state that it has messages awaiting delivery |
| US5394402A (en) * | 1993-06-17 | 1995-02-28 | Ascom Timeplex Trading Ag | Hub for segmented virtual local area network with shared media access |
| US6094575A (en) * | 1993-11-01 | 2000-07-25 | Omnipoint Corporation | Communication system and method |
| JPH0923254A (en) * | 1995-07-05 | 1997-01-21 | Fujitsu Ltd | Inter-system data link system |
| US6122287A (en) * | 1996-02-09 | 2000-09-19 | Microcom Systems, Inc. | Method and apparatus for detecting switched network protocols |
| DE69636291T2 (en) | 1996-03-14 | 2007-06-14 | T-Mobile Deutschland Gmbh | Telematics terminal for road traffic applications |
| US5802319A (en) * | 1996-10-23 | 1998-09-01 | Hewlett-Packard Company | Method and apparatus for employing an intelligent agent to cause a packet to be sent to update a bridge's filtering database when a station is moved in a network |
| US6041058A (en) * | 1997-09-11 | 2000-03-21 | 3Com Corporation | Hardware filtering method and apparatus |
| US6105029A (en) * | 1997-09-17 | 2000-08-15 | International Business Machines Corporation | Retrieving network files through parallel channels |
| US6188694B1 (en) * | 1997-12-23 | 2001-02-13 | Cisco Technology, Inc. | Shared spanning tree protocol |
| US6515967B1 (en) * | 1998-06-30 | 2003-02-04 | Cisco Technology, Inc. | Method and apparatus for detecting a fault in a multicast routing infrastructure |
| US6249801B1 (en) * | 1998-07-15 | 2001-06-19 | Radware Ltd. | Load balancing |
| US6674713B1 (en) * | 1999-02-23 | 2004-01-06 | Cisco Technology, Inc. | Method and apparatus for providing continuous voice and call communications between a data network and a telephony network |
| US6324581B1 (en) * | 1999-03-03 | 2001-11-27 | Emc Corporation | File server system using file system storage, data movers, and an exchange of meta data among data movers for file locking and direct access to shared file systems |
| US6453354B1 (en) * | 1999-03-03 | 2002-09-17 | Emc Corporation | File server system using connection-oriented protocol and sharing data sets among data movers |
| US6772215B1 (en) * | 1999-04-09 | 2004-08-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for minimizing feedback responses in ARQ protocols |
| US6947394B1 (en) * | 1999-04-09 | 2005-09-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Flexible radio link control protocol |
| US6700871B1 (en) * | 1999-05-04 | 2004-03-02 | 3Com Corporation | Increased throughput across data network interface by dropping redundant packets |
| US6401127B1 (en) * | 1999-05-04 | 2002-06-04 | Cisco Technology, Inc. | Adaptive timer for LLC type 2 reliable transport in a computer network |
| US6680942B2 (en) * | 1999-07-02 | 2004-01-20 | Cisco Technology, Inc. | Directory services caching for network peer to peer service locator |
| US6674742B1 (en) * | 1999-07-08 | 2004-01-06 | Cisco Technology, Inc. | Automatic SDLC role configuration on router interfaces |
| US6873603B1 (en) * | 1999-12-23 | 2005-03-29 | Cisco Technology, Inc. | MAC address population protocol |
| US6775284B1 (en) * | 2000-01-07 | 2004-08-10 | International Business Machines Corporation | Method and system for frame and protocol classification |
| US6667954B1 (en) * | 2000-02-10 | 2003-12-23 | Tellabs Operations, Inc. | Methods and apparatus for selecting the better cell from redundant streams within a cell-oriented environment |
| US7506034B2 (en) | 2000-03-03 | 2009-03-17 | Intel Corporation | Methods and apparatus for off loading content servers through direct file transfer from a storage center to an end-user |
| US8281022B1 (en) | 2000-06-30 | 2012-10-02 | Emc Corporation | Method and apparatus for implementing high-performance, scaleable data processing and storage systems |
| US6831898B1 (en) * | 2000-08-16 | 2004-12-14 | Cisco Systems, Inc. | Multiple packet paths to improve reliability in an IP network |
| US6937576B1 (en) * | 2000-10-17 | 2005-08-30 | Cisco Technology, Inc. | Multiple instance spanning tree protocol |
| US6970939B2 (en) * | 2000-10-26 | 2005-11-29 | Intel Corporation | Method and apparatus for large payload distribution in a network |
| CA2360963A1 (en) * | 2000-11-03 | 2002-05-03 | Telecommunications Research Laboratories | Topological design of survivable mesh-based transport networks |
| US6853641B2 (en) * | 2000-12-20 | 2005-02-08 | Nortel Networks Limited | Method of protecting traffic in a mesh network |
| US6606690B2 (en) * | 2001-02-20 | 2003-08-12 | Hewlett-Packard Development Company, L.P. | System and method for accessing a storage area network as network attached storage |
| US20020150100A1 (en) * | 2001-02-22 | 2002-10-17 | White Timothy Richard | Method and apparatus for adaptive frame fragmentation |
| JP2002353998A (en) * | 2001-05-30 | 2002-12-06 | Nec Corp | Communication unit and network system employing the same, and spanning tree buildup method |
| US20030005145A1 (en) * | 2001-06-12 | 2003-01-02 | Qosient Llc | Network service assurance with comparison of flow activity captured outside of a service network with flow activity captured in or at an interface of a service network |
| AU2002313583A1 (en) * | 2001-08-01 | 2003-02-17 | Actona Technologies Ltd. | Virtual file-sharing network |
| US20030223379A1 (en) * | 2002-05-28 | 2003-12-04 | Xuguang Yang | Method and system for inter-domain loop protection using a hierarchy of loop resolving protocols |
| JP3849929B2 (en) * | 2002-06-14 | 2006-11-22 | Ｋｄｄｉ株式会社 | Wireless LAN system for virtual LAN |
| DE60233760D1 (en) * | 2002-06-19 | 2009-10-29 | Ericsson Telefon Ab L M | NETWORK SETUP DRIVER ARCHITECTURE |
| US7406082B2 (en) * | 2002-09-30 | 2008-07-29 | Lucent Technologies Inc. | Sequence number schemes for acceptance/rejection of duplicated packets in a packet-based data network |
| US7292581B2 (en) * | 2002-10-24 | 2007-11-06 | Cisco Technology, Inc. | Large-scale layer 2 metropolitan area network |
| US7475142B2 (en) * | 2002-12-06 | 2009-01-06 | Cisco Technology, Inc. | CIFS for scalable NAS architecture |
| US20040139167A1 (en) * | 2002-12-06 | 2004-07-15 | Andiamo Systems Inc., A Delaware Corporation | Apparatus and method for a scalable network attach storage system |
| US20070038697A1 (en) * | 2005-08-03 | 2007-02-15 | Eyal Zimran | Multi-protocol namespace server |
| US20070088702A1 (en) * | 2005-10-03 | 2007-04-19 | Fridella Stephen A | Intelligent network client for multi-protocol namespace redirection |
-
2002
- 2002-12-06 US US10/313,305 patent/US7443845B2/en active Active
-
2003
- 2003-11-19 AU AU2003294395A patent/AU2003294395A1/en not_active Abandoned
- 2003-11-19 CA CA002508748A patent/CA2508748A1/en not_active Abandoned
- 2003-11-19 WO PCT/US2003/037123 patent/WO2004054207A2/en not_active Application Discontinuation
- 2003-11-19 CN CN200380105301.0A patent/CN1729675A/en active Pending
- 2003-11-19 EP EP03789878A patent/EP1568191A2/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| US7443845B2 (en) | 2008-10-28 |
| EP1568191A2 (en) | 2005-08-31 |
| CN1729675A (en) | 2006-02-01 |
| US20040109443A1 (en) | 2004-06-10 |
| WO2004054207A2 (en) | 2004-06-24 |
| AU2003294395A1 (en) | 2004-06-30 |
| WO2004054207A3 (en) | 2004-08-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7443845B2 (en) | Apparatus and method for a lightweight, reliable, packet-based transport protocol | |
| US10237153B2 (en) | Packet retransmission method and apparatus | |
| US7483376B2 (en) | Method and apparatus for discovering path maximum transmission unit (PMTU) | |
| JP4829896B2 (en) | Method, system and article for improved network performance by avoiding data corruption | |
| US7742454B2 (en) | Network performance by dynamically setting a reassembly timer based on network interface | |
| US7369498B1 (en) | Congestion control method for a packet-switched network | |
| US7801021B1 (en) | Generic routing encapsulation tunnel keepalives | |
| US5519704A (en) | Reliable transport protocol for internetwork routing | |
| US6519223B1 (en) | System and method for implementing a semi reliable retransmission protocol | |
| KR100785293B1 (en) | System and Method for TCP Congestion Control Using Multiple TCP ACKs | |
| US6219713B1 (en) | Method and apparatus for adjustment of TCP sliding window with information about network conditions | |
| US8072898B2 (en) | Method for managing a transmission of data streams on a transport channel of a tunnel, corresponding tunnel end-point and computer-readable storage medium | |
| US6487689B1 (en) | Receiver initiated recovery algorithm (RIRA) for the layer 2 tunneling protocol (L2TP) | |
| US20050195821A1 (en) | Method and apparatus for dynamically controlling traffic in wireless station | |
| US20080212613A1 (en) | Multilink meshed transport service | |
| US20150215224A1 (en) | Positive feedback ethernet link flow control for promoting lossless ethernet | |
| US9584425B2 (en) | Bandwidth optimization using coalesced DUP ACKs | |
| US7577136B1 (en) | Ethernet switch fabric interface | |
| US20150055482A1 (en) | TCP Extended Fast Recovery and Segment Timing | |
| US20080101237A1 (en) | Communication device | |
| Cisco | Frame Relay Commands | |
| Jungmaier et al. | On SCTP multi-homing performance | |
| US20140369189A1 (en) | Method of controlling packet transmission in network system and network system transmitting packet using pseudo-tcp agent | |
| JPH0738612A (en) | Gateway | |
| Kolesnikov et al. | Load Generation at Transport Layer Service Interfaces |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |