`
`RFC 793: Transmission Control Protocol
`RFC 1001: Protocol Standard for a NetBIOS Service on a TCP/UDPTransport: Concepts and Methods
`RFC 1122: Requirements for Internet Hosts — Communication Lavers
`A Unifying Syntaxforthe Expression ofNames tt Addresses ofObjects
`RFC 1630: Universal Resource Identifiers WWW
`on the Network as used in the World-Wide Web
`RFC 1738: Uniform Resource Locators (URL)
`RFC 2187: Application of Internet Cache Protocol (ICP), version 2
`RFC 2616: Hypertext Transfer Protocol + HTTP/1.1
`RFC 2960: Stream Control Transmission Protocol
`RFC 6520: Transport Layer Security (TLS)and Datagram
`Transport Laver Security (DTLS) Heartbeat Extension
`
`
`
`I, Sandy Ginoza, hereby declare that all statements mate herein are of my own
`
`knowledge and are true andthatall statements made on information andbelief are believed to be
`
`true; and further that these statements were made with the knowledge that willful false
`
`statements and the like so made are punishable by fine or imprisonment, or both, under Section
`
`1001 of Title 18 of the United States Code:
`
`1.
`
`Iam an employee of Association ManagementSolutions, LLC (AMS), which
`
`acts under contract to the IETF Administration LLC (IETF) asthe operator of the RFC
`
`Production Center. The RFC Production Centeris part of thé "RFC Editor" function, which
`
`prepares documents for publication and placesfiles in an online repository for the
`
`authoritative Request for Comments (RFC)series of documents (RFC Series), and preserves
`
`records relating to these documents. The RFC Series includes, among otherthings, the series
`
`of Internet standards developed by the IETF.I holdthe position of Director of the RFC
`
`Production Center. I began employment with AMSinthis capacity on 6 January 2010.
`
`
`Ex. 1011 - Page 1
`Ex. 1011 - Page 1
`
`Code200, UABv. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 1 of 686
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 1 of 686
`
`
`
`2.
`
`Among myresponsibilities as Director of the RFC Production Center, I act as
`
`the custodian ofrecordsrelating to the RFC Series, and I am familiar with the record keeping
`
`practices relating to the RFC Series, including the creation and maintenanceof such records.
`
`3,
`
`From June 1999 to 5 January 2010, I was an employeeof the Information
`
`SciencesInstitute at University of Southern California (ISI). I held variousposition titles with
`
`the RFC Editor project at ISI, ending with Senior Editor.
`
`4.
`
`The RFC Editor function was conducted by ISI under contract to the United
`
`States governmentprior to 1998. In 1998, ISOC,in furtheranceof its IETFactivity, entered into
`
`the first in a series of contracts with ISI providing for ISI's performance of the RFC Editor
`
`function. Beginning in 2010, certain aspects of the RFC Editor function were assumed by the
`
`RFC Production Center operation of AMS undercontract to ISOC (acting through its IETF
`
`function and, in particular, the IETF Administrative Oversight Committee (now the IETF
`
`Administration LLC (IETF)). The business records of the RFC Editorfunction, as it was
`
`conducted by ISI, are currently housed on the computer systems of AMS,as contractor to the
`
`IETF.
`
`5,
`
`I makethis declaration based on my personal| knowledge and information
`
`
`
`contained in the business records of the RFC Editor as they are currently housed at AMS,or
`
`confirmation with other responsible RFC Editor personnel with such knowledge.
`
`6.
`
`Prior to 1998, the RFC Editor's regular practice was to publish RFCs, making
`
`them available from a repository via FTP. When a new RFC|waspublished, an announcement
`
`of its publication, with information on how to access the RFC, would be typically sent out
`
`within 24 hours of the publication.
`
`tees
`Ex. 1011 - Page 2
`Ex. 1011 - Page 2
`
`Code200, UABv. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 2 of 686
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 2 of 686
`
`
`
`7.
`
`Since 1998, the RFC Editor’s regular practice was to publish RFCs, making
`
`them available on the RFC Editor website or via FTP. When a new RFC waspublished, an
`
`announcementof its publication, with information on how to access the RFC, would be
`
`typically sent out within 24 hours of the publication. The announcement would go outtoall
`
`subscribers and a contemporaneouselectronic record of the announcementis kept in the IETF
`
`mail archive that is available online.
`
`8.
`
`Beginning in 1998, any RFC published on the RFC Editor website or via FTP
`
`was reasonably accessible to the public and was disseminated or otherwise available to the extent
`
`that persons interested and ordinarily skilled in the subject matter or art exercising reasonable
`
`diligence could havelocated it. In particular, the RFCs were indexed and placedin a public
`
`repository.
`
`9.
`
`The RFCsare kept in an online repository in the course of the RFC Editor's
`
`
`
`regularly conductedactivity and ordinary course of business. The records are made pursuantto
`
`established procedures and are relied upon by the RFC Editor in the performanceofits functions.
`
`10.
`
`11.
`
`It is the regular practice of the RFC Editor to make and keep the RFCrecords.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conduct in publishing RFCs, I have determined that the publication date of RFC 793 was no
`
`later than October 1992, at which time it was reasonably accessible to the public either on the
`
`RFC Editor website or via FTP from a repository. An announcementofits publication also
`
`would have been sent out to subscribers within 24 hoursofits
`
`is attached to this declaration as Exhibit 1.
`
`publication. A copy of that RFC
`
`12.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conduct in publishing RFCs, I have determinedthat the publication date of RFC 1001 was no
`
`
`
`
`
`Ex. 1011 - Page 3
`Ex. 1011 - Page 3
`
`Code200, UABv. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 3 of 686
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 3 of 686
`
`
`
`
`
`14.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conduct in publishing RFCs, I have determinedthat the publication date of RFC 1630 was no
`
`later than June 1994, at which timeit was reasonably accessible to the public either on the RFC
`
`Editor website or via FTP from a repository. An announcementofits publication also would
`
`have been sent out to subscribers within 24 hoursof its publication. A copy of that RFC is
`
`attachedto this declaration as Exhibit 4.
`
`15.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conduct in publishing RFCs, I have determinedthat the publication date of RFC 1738 was no
`
`later than December 1994, at which time it was reasonably accessible to the public either on the
`
`RFC Editor website or via FTP from a repository. An announcementofits publication also
`
`would have been sent out to subscribers within 24 hoursofits publication. A copy of that RFC
`
`is attached to this declaration as Exhibit 5.
`
`later than October 1992, at which time it was reasonably accessible to the public either on the
`
`RFC Editor website or via FTP from a repository. An announcementofits publication also
`
`would have been sent out to subscribers within 24 hours of its|publication. A copy of that RFC
`
`is attached to this declaration as Exhibit 2.
`
`13.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conduct in publishing RFCs, I have determined that the publication date of RFC 1122 was no
`
`later than October 1989, at which time it was reasonably accessibleto the public either on the
`
`RFC Editor website or via FTP from a repository. An announcementof its publication also
`
`would have been sent out to subscribers within 24 hoursofits|publication. A copy of that RFC
`
`is attached to this declaration as Exhibit 3.
`
`
`Ex. 1011 - Page 4
`Ex. 1011 - Page 4
`Code200, UABv. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page4 of 686
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 4 of 686
`
`
`
`16.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conduct in publishing RFCs, I have determinedthat the publication date of RFC 2187 was no
`
`later than September 1997, at which time it was reasonably accessible to the public either on the
`
`RFC Editor website or via FTP from a repository. An announcementofits publication also
`
`would have been sent out to subscribers within 24 hoursofits|publication. A copy of that RFC
`
`is attached to this declaration as Exhibit 6.
`
`17.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conduct in publishing RFCs, I have determined that the publication date of RFC 2616 was no
`
`later than June 1999, at which time it was reasonably accessible to the public either on the RFC
`
`Editor website or via FTP from a repository. An announcementofits publication also would
`
`have been sent out to subscribers within 24 hoursof its publication. A copy of that RFC is
`
`
`
`attached to this declaration as Exhibit 7.
`
`18.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conduct in publishing RFCs, I have determinedthat the publication date of RFC 2960 wasno
`
`later than October 2000, at which time it was reasonably accessible to the public either on the
`
`RFC Editor website or via FTP from a repository. An announcementof its publication also
`
`would have been sent out to subscribers within 24 hoursofits publication. A copy of that RFC
`
`is attached to this declaration as Exhibit 8.
`
`19.
`
`Based on the business records for the RFC Editor and the RFC Editor’s course
`
`of conductin publishing RFCs, I have determinedthat the publication date of RFC 6520 wasno
`
`later than February 2012, at which time it was reasonably accessible to the public either on the
`
`RFC Editor website or via FTP from a repository. An announcementofits publication also
`
`
`Ex. 1011 - Page 5
`Ex. 1011 - Page 5
`
`Code200, UABv. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 5 of 686
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 5 of 686
`
`
`
`would havebeensent out to subscribers within 24 hoursofits publication. A copy of that RFC
`
`is attached to this declaration as Exhibit 9.
`
`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penalty of
`
`perjury underthe laws of the United States of America that the foregoingis true and correct
`
`and that the foregoing is based upon personal knowledge and
`
` information andis believed to be
`
`true.
`
`Date.
`
`2 September 202)
`
`4827-3367-0647
`
`
`
`
`Ex. 1011 - Page 6
`Ex. 1011 - Page 6
`
`Code200, UABv. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 6 of 686
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 6 of 686
`
`
`
`EXHIBIT 1
`EXHIBIT 1
`
`Ex. 1011 - Page 7
`Ex. 1011 - Page 7
`
`Code200, UABv. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page7 of 686
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 7 of 686
`
`
`
`RFC: 793
`
`
`
`
`
`
`
` TRANSMISSION CONTROL PROTOCOL
`
`
` DARPA INTERNET PROGRAM
`
` PROTOCOL SPECIFICATION
`
`
`
` September 1981
`
` prepared for
`
` Defense Advanced Research Projects Agency
` Information Processing Techniques Office
` 1400 Wilson Boulevard
` Arlington, Virginia 22209
`
` by
`
` Information Sciences Institute
` University of Southern California
` 4676 Admiralty Way
` Marina del Rey, California 90291
`
`Ex. 1011 - Page 8
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 8 of 686
`
`
`
`Ex. 1011 - Page 9
`Ex. 1011 - Page 9
`
`Code200, UABv. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 9 of 686
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 9 of 686
`
`
`
`September 1981
` Transmission Control Protocol
`
` TABLE OF CONTENTS
`
` PREFACE ........................................................ iii
`
`1. INTRODUCTION ..................................................... 1
`
` 1.1 Motivation .................................................... 1
` 1.2 Scope ......................................................... 2
` 1.3 About This Document ........................................... 2
` 1.4 Interfaces .................................................... 3
` 1.5 Operation ..................................................... 3
`
`2. PHILOSOPHY ....................................................... 7
`
` 2.1 Elements of the Internetwork System ........................... 7
` 2.2 Model of Operation ............................................ 7
` 2.3 The Host Environment .......................................... 8
` 2.4 Interfaces .................................................... 9
` 2.5 Relation to Other Protocols ................................... 9
` 2.6 Reliable Communication ........................................ 9
` 2.7 Connection Establishment and Clearing ........................ 10
` 2.8 Data Communication ........................................... 12
` 2.9 Precedence and Security ...................................... 13
` 2.10 Robustness Principle ......................................... 13
`
`3. FUNCTIONAL SPECIFICATION ........................................ 15
`
` 3.1 Header Format ................................................ 15
` 3.2 Terminology .................................................. 19
` 3.3 Sequence Numbers ............................................. 24
` 3.4 Establishing a connection .................................... 30
` 3.5 Closing a Connection ......................................... 37
` 3.6 Precedence and Security ...................................... 40
` 3.7 Data Communication ........................................... 40
` 3.8 Interfaces ................................................... 44
` 3.9 Event Processing ............................................. 52
`
`GLOSSARY ............................................................ 79
`
`REFERENCES .......................................................... 85
`
` [Page i]
`
`Ex. 1011 - Page 10
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 10 of 686
`
`
`
` September 1981
`Transmission Control Protocol
`
`[Page ii]
`
`Ex. 1011 - Page 11
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 11 of 686
`
`
`
`September 1981
` Transmission Control Protocol
`
` PREFACE
`
`This document describes the DoD Standard Transmission Control Protocol
`(TCP). There have been nine earlier editions of the ARPA TCP
`specification on which this standard is based, and the present text
`draws heavily from them. There have been many contributors to this work
`both in terms of concepts and in terms of text. This edition clarifies
`several details and removes the end-of-letter buffer-size adjustments,
`and redescribes the letter mechanism as a push function.
`
` Jon Postel
`
` Editor
`
` [Page iii]
`
`Ex. 1011 - Page 12
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 12 of 686
`
`
`
`Ex. 1011 - Page 13
`Ex. 1011 - Page 13
`
`Code200, UABv. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 13 of 686
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 13 of 686
`
`
`
`RFC: 793
`Replaces: RFC 761
`IENs: 129, 124, 112, 81,
`55, 44, 40, 27, 21, 5
`
` TRANSMISSION CONTROL PROTOCOL
`
` DARPA INTERNET PROGRAM
` PROTOCOL SPECIFICATION
`
` 1. INTRODUCTION
`
`The Transmission Control Protocol (TCP) is intended for use as a highly
`reliable host-to-host protocol between hosts in packet-switched computer
`communication networks, and in interconnected systems of such networks.
`
`This document describes the functions to be performed by the
`Transmission Control Protocol, the program that implements it, and its
`interface to programs or users that require its services.
`
`1.1. Motivation
`
` Computer communication systems are playing an increasingly important
` role in military, government, and civilian environments. This
` document focuses its attention primarily on military computer
` communication requirements, especially robustness in the presence of
` communication unreliability and availability in the presence of
` congestion, but many of these problems are found in the civilian and
` government sector as well.
`
` As strategic and tactical computer communication networks are
` developed and deployed, it is essential to provide means of
` interconnecting them and to provide standard interprocess
` communication protocols which can support a broad range of
` applications. In anticipation of the need for such standards, the
` Deputy Undersecretary of Defense for Research and Engineering has
` declared the Transmission Control Protocol (TCP) described herein to
` be a basis for DoD-wide inter-process communication protocol
` standardization.
`
` TCP is a connection-oriented, end-to-end reliable protocol designed to
` fit into a layered hierarchy of protocols which support multi-network
` applications. The TCP provides for reliable inter-process
` communication between pairs of processes in host computers attached to
` distinct but interconnected computer communication networks. Very few
` assumptions are made as to the reliability of the communication
` protocols below the TCP layer. TCP assumes it can obtain a simple,
` potentially unreliable datagram service from the lower level
` protocols. In principle, the TCP should be able to operate above a
` wide spectrum of communication systems ranging from hard-wired
` connections to packet-switched or circuit-switched networks.
`
` [Page 1]
`
`Ex. 1011 - Page 14
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 14 of 686
`
`
`
` September 1981
`Transmission Control Protocol
`Introduction
`
` TCP is based on concepts first described by Cerf and Kahn in [1]. The
` TCP fits into a layered protocol architecture just above a basic
` Internet Protocol [2] which provides a way for the TCP to send and
` receive variable-length segments of information enclosed in internet
` datagram "envelopes". The internet datagram provides a means for
` addressing source and destination TCPs in different networks. The
` internet protocol also deals with any fragmentation or reassembly of
` the TCP segments required to achieve transport and delivery through
` multiple networks and interconnecting gateways. The internet protocol
` also carries information on the precedence, security classification
` and compartmentation of the TCP segments, so this information can be
` communicated end-to-end across multiple networks.
`
` Protocol Layering
`
` +---------------------+
` | higher-level |
` +---------------------+
` | TCP |
` +---------------------+
` | internet protocol |
` +---------------------+
` |communication network|
` +---------------------+
`
` Figure 1
`
` Much of this document is written in the context of TCP implementations
` which are co-resident with higher level protocols in the host
` computer. Some computer systems will be connected to networks via
` front-end computers which house the TCP and internet protocol layers,
` as well as network specific software. The TCP specification describes
` an interface to the higher level protocols which appears to be
` implementable even for the front-end case, as long as a suitable
` host-to-front end protocol is implemented.
`
`1.2. Scope
`
` The TCP is intended to provide a reliable process-to-process
` communication service in a multinetwork environment. The TCP is
` intended to be a host-to-host protocol in common use in multiple
` networks.
`
`1.3. About this Document
`
` This document represents a specification of the behavior required of
` any TCP implementation, both in its interactions with higher level
` protocols and in its interactions with other TCPs. The rest of this
`
`[Page 2]
`
`Ex. 1011 - Page 15
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 15 of 686
`
`
`
`September 1981
` Transmission Control Protocol
` Introduction
`
` section offers a very brief view of the protocol interfaces and
` operation. Section 2 summarizes the philosophical basis for the TCP
` design. Section 3 offers both a detailed description of the actions
` required of TCP when various events occur (arrival of new segments,
` user calls, errors, etc.) and the details of the formats of TCP
` segments.
`
`1.4. Interfaces
`
` The TCP interfaces on one side to user or application processes and on
` the other side to a lower level protocol such as Internet Protocol.
`
` The interface between an application process and the TCP is
` illustrated in reasonable detail. This interface consists of a set of
` calls much like the calls an operating system provides to an
` application process for manipulating files. For example, there are
` calls to open and close connections and to send and receive data on
` established connections. It is also expected that the TCP can
` asynchronously communicate with application programs. Although
` considerable freedom is permitted to TCP implementors to design
` interfaces which are appropriate to a particular operating system
` environment, a minimum functionality is required at the TCP/user
` interface for any valid implementation.
`
` The interface between TCP and lower level protocol is essentially
` unspecified except that it is assumed there is a mechanism whereby the
` two levels can asynchronously pass information to each other.
` Typically, one expects the lower level protocol to specify this
` interface. TCP is designed to work in a very general environment of
` interconnected networks. The lower level protocol which is assumed
` throughout this document is the Internet Protocol [2].
`
`1.5. Operation
`
` As noted above, the primary purpose of the TCP is to provide reliable,
` securable logical circuit or connection service between pairs of
` processes. To provide this service on top of a less reliable internet
` communication system requires facilities in the following areas:
`
` Basic Data Transfer
` Reliability
` Flow Control
` Multiplexing
` Connections
` Precedence and Security
`
` The basic operation of the TCP in each of these areas is described in
` the following paragraphs.
`
` [Page 3]
`
`Ex. 1011 - Page 16
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 16 of 686
`
`
`
` September 1981
`Transmission Control Protocol
`Introduction
`
` Basic Data Transfer:
`
` The TCP is able to transfer a continuous stream of octets in each
` direction between its users by packaging some number of octets into
` segments for transmission through the internet system. In general,
` the TCPs decide when to block and forward data at their own
` convenience.
`
` Sometimes users need to be sure that all the data they have
` submitted to the TCP has been transmitted. For this purpose a push
` function is defined. To assure that data submitted to a TCP is
` actually transmitted the sending user indicates that it should be
` pushed through to the receiving user. A push causes the TCPs to
` promptly forward and deliver data up to that point to the receiver.
` The exact push point might not be visible to the receiving user and
` the push function does not supply a record boundary marker.
`
` Reliability:
`
` The TCP must recover from data that is damaged, lost, duplicated, or
` delivered out of order by the internet communication system. This
` is achieved by assigning a sequence number to each octet
` transmitted, and requiring a positive acknowledgment (ACK) from the
` receiving TCP. If the ACK is not received within a timeout
` interval, the data is retransmitted. At the receiver, the sequence
` numbers are used to correctly order segments that may be received
` out of order and to eliminate duplicates. Damage is handled by
` adding a checksum to each segment transmitted, checking it at the
` receiver, and discarding damaged segments.
`
` As long as the TCPs continue to function properly and the internet
` system does not become completely partitioned, no transmission
` errors will affect the correct delivery of data. TCP recovers from
` internet communication system errors.
`
` Flow Control:
`
` TCP provides a means for the receiver to govern the amount of data
` sent by the sender. This is achieved by returning a "window" with
` every ACK indicating a range of acceptable sequence numbers beyond
` the last segment successfully received. The window indicates an
` allowed number of octets that the sender may transmit before
` receiving further permission.
`
`[Page 4]
`
`Ex. 1011 - Page 17
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 17 of 686
`
`
`
`September 1981
` Transmission Control Protocol
` Introduction
`
` Multiplexing:
`
` To allow for many processes within a single Host to use TCP
` communication facilities simultaneously, the TCP provides a set of
` addresses or ports within each host. Concatenated with the network
` and host addresses from the internet communication layer, this forms
` a socket. A pair of sockets uniquely identifies each connection.
` That is, a socket may be simultaneously used in multiple
` connections.
`
` The binding of ports to processes is handled independently by each
` Host. However, it proves useful to attach frequently used processes
` (e.g., a "logger" or timesharing service) to fixed sockets which are
` made known to the public. These services can then be accessed
` through the known addresses. Establishing and learning the port
` addresses of other processes may involve more dynamic mechanisms.
`
` Connections:
`
` The reliability and flow control mechanisms described above require
` that TCPs initialize and maintain certain status information for
` each data stream. The combination of this information, including
` sockets, sequence numbers, and window sizes, is called a connection.
` Each connection is uniquely specified by a pair of sockets
` identifying its two sides.
`
` When two processes wish to communicate, their TCP’s must first
` establish a connection (initialize the status information on each
` side). When their communication is complete, the connection is
` terminated or closed to free the resources for other uses.
`
` Since connections must be established between unreliable hosts and
` over the unreliable internet communication system, a handshake
` mechanism with clock-based sequence numbers is used to avoid
` erroneous initialization of connections.
`
` Precedence and Security:
`
` The users of TCP may indicate the security and precedence of their
` communication. Provision is made for default values to be used when
` these features are not needed.
`
`
`
` [Page 5]
`
`Ex. 1011 - Page 18
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 18 of 686
`
`
`
` September 1981
`Transmission Control Protocol
`
`[Page 6]
`
`Ex. 1011 - Page 19
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 19 of 686
`
`
`
`September 1981
` Transmission Control Protocol
`
` 2. PHILOSOPHY
`
`2.1. Elements of the Internetwork System
`
` The internetwork environment consists of hosts connected to networks
` which are in turn interconnected via gateways. It is assumed here
` that the networks may be either local networks (e.g., the ETHERNET) or
` large networks (e.g., the ARPANET), but in any case are based on
` packet switching technology. The active agents that produce and
` consume messages are processes. Various levels of protocols in the
` networks, the gateways, and the hosts support an interprocess
` communication system that provides two-way data flow on logical
` connections between process ports.
`
` The term packet is used generically here to mean the data of one
` transaction between a host and its network. The format of data blocks
` exchanged within the a network will generally not be of concern to us.
`
` Hosts are computers attached to a network, and from the communication
` network’s point of view, are the sources and destinations of packets.
` Processes are viewed as the active elements in host computers (in
` accordance with the fairly common definition of a process as a program
` in execution). Even terminals and files or other I/O devices are
` viewed as communicating with each other through the use of processes.
` Thus, all communication is viewed as inter-process communication.
`
` Since a process may need to distinguish among several communication
` streams between itself and another process (or processes), we imagine
` that each process may have a number of ports through which it
` communicates with the ports of other processes.
`
`2.2. Model of Operation
`
` Processes transmit data by calling on the TCP and passing buffers of
` data as arguments. The TCP packages the data from these buffers into
` segments and calls on the internet module to transmit each segment to
` the destination TCP. The receiving TCP places the data from a segment
` into the receiving user’s buffer and notifies the receiving user. The
` TCPs include control information in the segments which they use to
` ensure reliable ordered data transmission.
`
` The model of internet communication is that there is an internet
` protocol module associated with each TCP which provides an interface
` to the local network. This internet module packages TCP segments
` inside internet datagrams and routes these datagrams to a destination
` internet module or intermediate gateway. To transmit the datagram
` through the local network, it is embedded in a local network packet.
`
` The packet switches may perform further packaging, fragmentation, or
`
` [Page 7]
`
`Ex. 1011 - Page 20
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1011
`Page 20 of 686
`
`
`
` September 1981
`Transmission Control Protocol
`Philosophy
`
` other operations to achieve the delivery of the local packet to the
` destination internet module.
`
` At a gateway between networks, the internet datagram is "unwrapped"
` from its local packet and examined t