*S3 0 Posted January 3, 2017 Share Posted January 3, 2017 (edited) The following document is a DRAFT. Any information here may be revised at any time, and suggestions are more than welcome. Rev. #2017032401 (0.2.0) Abstract This draft defines the OCR (OCranet Relay) protocol as part of the OCranet family of protocols. This document outlines how OCR forms connections, how data is fowarded, and the structure of a data segment used in an OCR network. Rationale An agreement between computers in terms of how to communicate is important in any data network. In the past, there have been several attempts to build networks to transfer data bewteen machines, but it has been hard to come by a family of protocols that are unobtrusive, portable, passive, reliable, fast, versatile, easy to implement, and easy to maintain all at the same time. Meanwhile, in time, curiosity has brought up questions of inter-server communication; Data transfer between OpenComputers machines accross multiple Minecraft servers. It is the research on this subject that has brought attention to a new protocol that is capable of fulfilling all of these requirements. Thus, as a pun on ARPANet, the OCranet is born. OCranet Relay protocol (OCR for short) is responsible for gluing the OCranet together in hopes of forming a large scale network for all of us. Conventions This document follows all guidelines proposed in RFC 2119. Circuit switching, paths, and channels OCR networks form a circuit switched topology. This means that routing is predetermined for any given connection; Instead of determining the path of data for every segment, the path is determined when the connection is first initiated and BEFORE communication with the destination host begins. Unless a network failure occurs, any data part of a connection should always follow the same path to get to its destination until the connection is torn down. Virtual Paths OCR makes use of virtual paths which represent the physical or virtual next-hop destinations a host may reach. The wire connecting each computer face to face in a network is called a LOOP. There are two standard models for constructing an OCR network: internal routing, or network interconnection only. Using an internal routing model, OCR is used to route between each host on a network, while on the other hand a network interconnection only model uses OCR only for interconnecting each network, but not the hosts inside of them. A complex network can be built by arranging multiple loops and connecting them together by using one or more OCR switch(es) [DOCUMENTED BELOW]. Using an internal routing model, each host on a loop is identified by a Virtual Path Identifier (VPI). However, using a network interconnection only model, only each network has a particular VPI. This number is 8 bits, therefore there may be a total of 256 hosts on the same loop. When using OCR with an internal routing model, VPI 0 is RESERVED for speaking directly with the host. When using OCR with a network interconnection only model, VPI 0 should be reserved for speaking to that network (ex. a switch that governs that network). Virtual Channels Each connection from a host is represented by a single Virtual Channel Identifier (VCI). a Virtual Channel represents a connection within a Virtual Path. The Virtual Channel Identifier is 16 bit, therefore every host can simultaneously handle a maximum of (256 * 65536) = 16,777,216 connections at any time. Bear in mind that VPI 0 is reserved, so more likely your maximum sustainable connection limit will realistically be (255 * 65536) = 16,711,680 simultaneous connections. Switches To separate multiple loops, a switch is deployed and is responsible for forwarding in that direction. switches are REQUIRED at minimum to be responsible for keeping track of VPI and VCI pairs as well as forwarding data along these Virtual Paths via their Virtual Channels. In order for a switch to perform its job, additional features are RECOMMENDED. These features should control the use of Virtual Path and Virtual Channel propagation. One such example of a feature is a dynamic ROUTING PROTOCOL which might be responsible for performing an address or telephone number lookup and building a chain of Virtual Path and Virtual Channel pairs across an OCranet network. The complete concept of OCR routing protocols intended to be extensible and separate from OCR, and therefore is outside the scope of this document. Forwarding The process of re-transmitting a data segment to the next-hop switch or computer is called forwarding. The Virtual Path Identifier and Virtual Channel Identifier always indicates the VPI and VCI pair that matches on the next-hop switch. This means that if the computer you are speaking to is on VPI 3, VCI 7 of the next-hop switch, then your data segment MUST have a header with a Virtual Path Identifier of 3 and Virtual Channel Identifier of 7 when it is read by that switch. It is normal for the VPI and VCI fields in each data segment to be replaced at every hop along the way while propagating through a series of loops in a network. Services To promote extensibility, versatility, and hopefully the reliability of OCR networks VPI 0 is reserved for speaking directly to the switch. It is RECOMMENDED that each service has its own Virtual Channel Identifier at VPI 0. Furthermore, VCI 0 through VCI 4 via VPI 0 are RESERVED for future use by OCR and MUST NOT be used until an applicable standard suitably fits. It is RECCOMMENDED that features such as ROUTING PROTOCOL are provided on VPI 0, given a particular (and hopefully unchanging) VCI. Cell format Every segment of data transferred in an OCR network is called a 'cell'. Each cell is exactly the same size to reduce jitter effects, normalizing propagation latency. A cell is defined as a 51 octet data structure that contains a 3 byte header, providing 48 bytes of data transfer per cell. The format of the header is as follows: 0 15 23 <-- Bit # *----------------*--------* | VCI | VPI | *----------------*--------* Since revision 0.1.x, the order of this structure has been reversed to increase performance of the protocol by providing proper word alignment. This makes cut through switching a little more latent, but ensures that the datatypes align properly. Edited March 25, 2017 by *S3 New revision! Performance fixes, clarification of VPI usage. Quote Link to post Share on other sites
