Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Search the Community

Showing results for tags 'draft'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • OpenComputers
    • Announcements
    • Feedback
    • IRC
  • Code Central
    • Support
    • Showcase
    • Tutorials
  • Addons & More
    • Addons Mods
    • Architectures
    • OpenEngineering Task Force
  • General
    • Lounge
    • Forum Games
    • Showcase
    • Servers
  • Archives
    • Public Archives

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Minecraft


GitHub


IRC


Location


Interests

Found 5 results

  1. this is just a draft, feel free to suggest whatever. Abstract This document describes the URF, intended to make mass file exchange easier. Rationale There are many competing methods of exchanging large amounts of files, and many are incomplete, such as TAR implementations, or proprietary, such as NeoPAKv1. With this in mind, a standard format will make file exchange less error prone. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. All integers are unsigned arbitrary length integers as specified in the Document, unless otherwise specified. All strings are encoded with UTF-8, prepended with an integer corresponding to the length of the string in bytes. Character specifications such as NULL and DC1 are part of US ASCII, unless otherwise specified. Concepts Signature: Data at the beginning of the File, marking the File as a URF format archive, and specifying the version. File Table: Data structure containing all file information. Entry: Any data sub-structure in the File Table. Entry Specifier byte: A byte describing how to decode the data contained in an Entry. Object: A filesystem structure, i.e.. "file" or "directory". Attributes: Data describing the size, offset, parent Object, and Object ID of an Object. Extended Attributes: Data describing non-core attributes such as Permissions, Owner, Security, etc. Producer: A program or process that generates data in this format. Consumer: A program or process that consumes data in this format. Arbitrary length integers Arbitrary length integers (ALIs) MAY be over 64-bits in precision. ALIs are little endian. For each byte, add the value of the first seven bits, shifted by 7 times the number of characters currently read bits, to the the read value and repeat until the 8th bit is 0. Signature The Signature MUST be URF followed by a DC1 character, or an unsigned 32-bit little endian integer equal to 1431455249. The next two bytes MUST be the version number, the first being the major version, the second being the minor version. The next two bytes MUST be DC2 followed by a NULL character. File Table The File Table MUST start after the Signature. This MUST contain all Entries, and MUST end with an EOH Entry. See EOH Entry. Entry An Entry MUST start with an Entry Specifier byte. The Entry Specifier byte MUST be followed with an integer specifying the length. Data contained SHOULD be skipped if the Entry Specifier byte allows and the Entry Type is not understood. Entry Specifier byte An Entry Specifier byte MUST have the 7th bit set to 1. If the Consumer comes across an entry with the 7th bit not set to 1, the Consumer MUST stop reading the file and raise a fatal error. The 6th byte specifies if the entry is critical. If the entry is critical and not understood, the Consumer should raise a fatal error; if the entry is non-critical, the Consumer SHOULD skip the entry and continue reading the file. If the 8th byte is set to 1, the Entry is a non-standard extension. Vendors MAY use this range for vendor-specific data. Filesystem Structure Any Object MUST have a Parent ID and an Object ID. Object ID 0 is reserved for the root directory. File naming conventions Object names MUST NOT contain any type of slash. Object names must also be of the 8.3 format, though the full name MAY be specified with Extended Attributes. Full names in Attributes MUST NOT contain any type of slash. File offsets File offsets are relative to the end of the File Table. Entry Type: File The Entry Specifier byte MUST be F, and the data contained MUST be the name as a string, followed by the file offset and file size represented as an integer, then followed by the Object ID and Parent ID. Entry type: Directory The Entry Specifier byte MUST be D, and the data contained MUST be the name as a string, followed by the Object ID and the Parent ID. Entry type: Extended Attributes The Entry Specifier byte MUST be x, and the data contained MUST be the Object ID of the Entry the Entry is describing, followed by a four byte Attribute and the value. Currently recognized attributes include: NAME: The long name of the Object. PERM: The POSIX-compatible permissions of the Object W32P: Win32-compatible permissions of the Object, which override POSIX permissions. OTIM: Creation time of the Object MTIM: Modification time of the Object CTIM: Metadata update time of the Object ATIM: Access time of the Object Entry type: EOH The Entry Specifier byte MUST be Z, and the data contained MUST be the offset required to reach the end of the file. Compressed URF naming convention In an environment with long names, the file extension SHOULD be urf followed by a period (.) and the compression method (i.e. gz, lzma, xz, deflate) In an environment with 8.3 names, the file extension MUST be one of the following: UMA for LZMA UXZ for XZ UGZ for Gzip UL4 for LZ4 UB2 for BZip2 TODO Document is incomplete. Document should outline how to build the Filesystem structure, etc. Document should be checked for clarity and rewritten if needed.
  2. THIS IS A DRAFT. It may change before becoming "official". Please feel free to suggest breaking changes. Abstract This document provides guidelines for dealing with EEPROMs and locating architecture-specific boot code. Rationale OpenComputers supports a wide variety of architectures. Even more so than in the real world, OpenComputers architectures can differ dramatically from one another. Some architectures run programs in a particular high-level language directly, while others simulate real or fictitious low-level ISAs. Some architectures natively deal with data in 8-bit units, while others have built-in advanced string handling and vector processing capabilities. In contrast with this variety, OpenComputers components have a standard interface. An EEPROM containing boot code can easily end up being used on the "wrong" architecture, to say nothing of boot disks. This standard aims to solve that problem, by providing architecture-aware guidelines for dealing with EEPROMs, and procedures for locating boot code on filesystem-based and sector-based boot media. It aims to be simple to implement on the widest possible variety of architectures. Conventions Unless otherwise specified, all references to text imply 7-bit ASCII codes. Behavior on encountering bytes with the high-bit set is undefined. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Architecture Identifier Each architecture must provide a unique, preferably meaningful identifier which is specific to that architecture. This is the Architecture Identifier, or AID. The AID SHOULD be the same as the Architecture.Name annotation for the architecture, which is usually the same as the name used in the tooltip of the CPU. An AID MUST contain no bytes other than the following characters: digits, upper and lowercase letters, periods (.), dashes (-), underscores (_), slashes (/), spaces. In addition, an AID MUST NOT begin with a space, end with a space, or contain a run of two or more spaces. An AID SHOULD begin with a capital letter, if for no other reason than to make boot code easier to tell apart from other files and directories in listings. A new AID SHOULD NOT contain spaces, unless it is required for compatibility. An architecture with multiple variants that are mutually incompatible SHOULD use different AIDs for each variant. Fallback schemes, such as one where multiple AIDs are tried, are architecture-specific and outside the scope of this document. CAB-aware EEPROM images ("CABE images") This section applies to architectures, EEPROM flashing utilities, and any hardcoded boot code (analogous to machine.lua in the "standard" Lua architecture). A CAB-aware EEPROM image (a "CABE image") MUST begin with "--[", followed by zero or more "=", followed by "[CABE:". This is the prefix string. A CAB-compliant architecture MUST be prepared to deal with any number of "=" between 0 and 7, and a CABE image SHOULD NOT use more than 7. The prefix string is followed by a single AID. This denotes the "intended architecture" for this CAB image. This is followed by one of two things: A colon (:), in which case the "main body" consists of the bytes following the colon, up until a valid suffix string is encountered. A suffix string, in which case the "main body" consists of the entire remainder of the image, and MUST be valid Lua 5.2 AND Lua 5.3 code. A "suffix string" consists of an ASCII "]", followed by the same number of "=" as were in the prefix string, followed by another "]". In order to be a valid suffix string, it MUST contain precisely the same number of "=" as the prefix string contains. In particular, an otherwise valid suffix string that contains more "=" than the prefix string MUST be treated exactly the same as any other non-suffix-string byte sequence. The "main body" contains the actual EEPROM data for that architecture. The interpretation of this data is architecture-defined. If a CABE image contains data after a valid suffix string, that data MUST be Lua code which is cross-compatible between the Lua 5.2 and 5.3 architectures provided by OpenComputers. If this is not the intended architecture of the CABE image, this code SHOULD consist solely of an informative error call. Any deviation whatsoever from this standard results in a non-CABE image. All handling of non-CABE images is architecture-specific, but a non-CABE image SHOULD be treated however the "main body" of a valid CABE image would be treated. The preferred file extension for CABE images is ".cabe". The preferred MIME type is "application/x-cabe-image", though "application/octet-stream" is acceptable. CABE images MUST NOT be distributed using any "text/*" MIME type, as doing so will almost certainly corrupt binary CABE images. Here is an example CABE image targeting a fictional architecture: --[[CABE:HyperTalk: ask "What is your name?" answer "Hello," && it & "!" ]] error"HyperTalk architecture required" And here is one targeting a built-in Lua architecture: --[[CABE:Lua 5.2]] for n=1,5 do computer.beep(2000, 0.1) end EEPROM-based transparent architecture switching A future OpenComputers release may add support for transparent architecture switching, through additional NBT data for EEPROMs. It is expected that this will consist of a single AID identifying the architecture the EEPROM is designed for. This section applies in the event of such support becoming available. To provide consistency to users, architectures SHOULD NOT attempt to implement any form of automatic architecture switching themselves. An EEPROM flashing utility SHOULD attempt to parse all images as CABE images. If successful, it SHOULD tag the EEPROM appropriately and burn only the "main body". Otherwise, it SHOULD remove any existing architecture tag from the EEPROM and burn the entire image. An architecture booting an EEPROM with a valid architecture tag SHOULD NOT also attempt to parse it as a CABE image. An architecture booting an EEPROM with no valid architecture tag SHOULD attempt to parse it as a CABE image, and MUST NOT affix an architecture tag itself. Boot code This section applies to EEPROMs intended as first-stage bootloaders, as well as programs intended to be booted by such EEPROMs. Bootloaders SHOULD, if the boot EEPROM contains a boot device UUID, attempt to boot from that device first. A boot EEPROM contains a boot device UUID if eeprom.getData() consists entirely of an ASCII UUID, or if it begins with an ASCII UUID followed by a null byte. Managed mode (filesystems) Bootloader behavior on managed filesystems: If "/<AID>" exists and is a directory, boot "/<AID>/boot". If "/<AID>" exists and is a file, boot "/<AID>". Any further cases are architecture-specific. If one of the above conditions are met, but its booting attempt fails, the booting process MUST NOT continue automatically. For instance, if "/<AID>" is a directory but booting "/<AID>/boot" fails, the bootloader MUST either fail with an error, or prompt a user for further action. Exactly what "booting" entails is architecture-specific. On a Lua architecture, it consists of loading a file as Lua code and then executing it. On low-level architectures, it might consist of loading a file's contents to a fixed RAM address and jumping into it. Architectures SHOULD provide a standard way for the first-stage bootloader to tell the booted code the UUID of the filesystem it was loaded from. Example: Consider a boot on the OC-ARM architecture. The bootloader checks if "/OC-ARM" exists. It does exist, and is a directory. The bootloader then attempts to boot "/OC-ARM/boot". It fails, because "/OC-ARM/boot" is not valid. It crashes the machine with an error message explaining the problem. Unmanaged mode (drives) A CAB-compliant bootable disk begins with a boot sector. This boot sector MUST be the first or second sector of the drive. If both the first and second sectors contain a valid boot sector, only the first one will be used. A boot sector begins with the ASCII string "CAB", followed by zero or more text boot records. This list of text records is terminated with an exclamation mark. If this exclamation mark is followed by the particular byte sequence {0x00, 0x1A, 0xCA, 0xBD} (null byte, CP/M end-of-file marker, two-byte magic number), then it is followed by zero or more binary boot records, terminated by a null byte. Boot records MUST NOT extend past the end of the boot sector. Architectures MAY specify that boot records for that architecture must be text or must be binary, and MAY specify that binary boot records must be a particular endianness and/or must be sector-aligned. Bootloaders for architectures that do not specify that boot records must be text or must be binary MUST support both. A text record matches ":<AID>=<offset>+<length>". <AID> is the AID for which the code is intended. <offset> is a decimal number, giving the byte offset at which to begin reading, OR "s" followed by a decimal number, giving the sector number at which to begin reading. <length> is a decimal number giving the number of bytes to read. A binary record is described by the following C99 structure: struct { uint8_t record_length; uint8_t flags; uint16_t load_start; uint32_t load_length; char aid[]; }; record_length is the number that must be added to the offset of this record to skip it. It MUST be equal to 8 + AID length + 1. flags is a bitfield. The following flags are defined: 0x40: If set, load_start is a sector number. If clear, load_start is a byte offset. 0x80: If set, load_start and load_length are little-endian. If clear, load_start and load_length are in network byte order (big-endian). load_start is either a sector number or a byte offset to begin the loading process at. load_length is the number of bytes to read. aid is the AID of the intended architecture, and MUST be null-terminated. As with managed mode, exactly what is done with the loaded data is architecture-specific. Bootloaders that only support binary records should consider a sector to be a valid boot sector if it begins with "CAB", and locate the end of the text boot records without parsing them by searching for the first "!". Bootloaders that only support text records need not consider any bytes past the first null byte. A boot sector that contains no records is valid, and MUST prevent any attempt to read possible subsequent boot sectors. Example 1: CAB:Lua 5.2=s3+17:Lua 5.3=s3+17:HyperTalk=384+5100! (followed directly by binary data:) 001A CABD (valid binary records follow) 0F (the length of the first record) C0 (little-endian, sector offset) 0900 (start at sector number 9) 0000 0100 (load 65536 bytes) 5342 3635 3032 00 (null-terminated string "SB6502") 00 (no more binary records) This drive contains valid boot code for Lua 5.2, Lua 5.3, HyperTalk, and SB6502. Lua 5.2 and 5.3 both use the same boot code, which is 17 bytes long and starts at the beginning of sector number 3. The HyperTalk boot code is 5100 bytes long and starts 384 bytes into the disk, which, when using 256-byte sectors, is halfway through the second sector. The SB6502 boot code is 65536 bytes long and starts at the beginning of sector number 9. Example 2: CAB! This is a valid boot sector, but contains no boot records. This is the safest way to mark a drive as non-bootable.
  3. Globally Engineered Routing Technology (GERT) is a networking protocol for OpenComputers that can network OC computers together, and connect different MC servers together via the Internet. It is also capable of linking real life computers to OC Computers. This post is dramatically being revised, but more information can be found at https://github.com/GlobalEmpire/GERT/wiki/GERTi For more questions, please either post in this thread, or message MajGenRelativity#4971, Gavle#9328, or TYKUHN2#5283 on Discord. Messaging MajGenRelativity on irc.esper.net is also an option if you can't/won't use Discord.
  4. THIS IS A DRAFT. It may change before becoming "official". Please feel free to suggest breaking changes. Abstract This document provides a binary interchange format, intended primarily to support generic component IO. Rationale OpenComputers' component bus is designed for high-level languages. It sends and receives groups of dynamically typed values. It is intended to be user-friendly and self-discoverable, and it has largely achieved this goal. However, with low-level architectures, there is no obvious, straightforward way to represent these values. This document aims to provide a standard representation, freeing individual architects from having to devise their own representations, and minimizing unnecessary differences between architectures. Every value that can be sent over an OpenComputers bus can be represented as described in this document, and (barring length restrictions) vice versa. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. All signed integers are two's-complement. Concepts Tag: Gives the type of a subsequent Value. Value: Data whose structure and meaning depend on its type. Tagged Value: A Tag, followed by a Value of the indicated type. Producer: A program or process that generates data in this format. Consumer: A program or process that consumes data in this format. Packed mode: A representation designed to occupy very little space. Unpacked mode: A representation designed to be easy to manipulate on 32-bit architectures. Tags A type tag denotes the type of a subsequent Value. In Packed mode, the tag is a 16-bit signed integer. In Unpacked mode, it is a 32-bit signed integer, aligned to a 4-byte boundary. Values String (UIFTAG_STRING = 0x0000–0x3FFF = 0–16383) A UTF-8 code sequence. The tag provides the length, in bytes, of the sequence. Producers MUST NOT generate invalid code sequences, including "modified UTF-8" conventions such as non-zero NUL and UTF-8 encoded surrogate pairs. Producers MUST NOT arbitrarily prefix strings with a spurious U+FEFF BYTE ORDER MARK. Consumer handling of invalid code sequences is undefined. If a Consumer encounters a String where a Byte Array is expected, the Consumer MAY incur a round-trip conversion to its native string type. This may mean that the bytes the Consumer actually sees differ from the original bytes where invalid code sequences occur. Consumers MUST handle NUL bytes in a String in an appropriate manner. Consumers MUST not assume that Strings are NUL-terminated—they are not. In Unpacked mode, additional zero bytes MUST be added to the end of the String, so that a subsequent Tag will be aligned to a 4-byte boundary. Byte Array (UIFTAG_BYTE_ARRAY = 0x4000-0x7FFF = 16384-32767) An arbitrary sequence of bytes. The tag, minus 16384, provides the length in bytes of the sequence. If a Consumer encounters a Byte Array where a String is expected, the Consumer MUST interpret the Byte Array as if it were a String of the given length. In Unpacked mode, additional zero bytes MUST be added to the end of the Byte Array, so that a subsequent Tag will be aligned to a 4-byte boundary. End (UIFTAG_END = 0x...FFFF = -1) A special tag signifying the end of an Array or Compound. Null (UIFTAG_NULL = 0x...FFFE = -2) Absence of a value. Equivalent to null and nil in various programming languages. (Note: there is no tag -3.) Double (UIFTAG_DOUBLE = 0x...FFFC = -4) A 64-bit IEEE 754 floating point value. Consumers that encounter a Double where an Integer is expected MAY fail. Producers that are producing a Double which has an exact Integer representation SHOULD produce that Integer instead. Integer (UIFTAG_INTEGER = 0x...FFFB = -5) A 32-bit signed integer. Consumers that encounter an Integer where a Double is expected MUST convert the Integer to a Double. Array (UIFTAG_ARRAY = 0x...FFFA = -6) A series of Tagged Values, in a particular order, terminated by an End. Compound (UIFTAG_COMPOUND = 0x...FFF9 = -7) A series of pairs of Tagged Values. The order of the pairs is not significant. Each pair consists of a Key and a Value, in that order. A Key may be any type except a Byte Array, a Null, an Array, or a Compound. A Value may be any type. The list is terminated by an End. If a Consumer encounters an End as the second element of a pair, the result is undefined. UUID (UIFTAG_UUID = 0x...FFF8 = -8) A 128-bit RFC 4122 UUID. Regardless of endianness, the bytes are in display order. Consumers that encounter a UUID where a String is expected MUST convert the UUID to its canonical string representation, in lowercase. Producers and Consumers alike should take note that a random sequence of bytes is not necessarily a valid UUID. True (UIFTAG_TRUE = 0x...FFF7 = -9) A boolean true value. False (UIFTAG_FALSE = 0x...FFF6 = -10) A boolean false value. TODO This document is incomplete. Still to be written: recommendations on endianness and packing, useful common optimizations.
  5. The following document is a DRAFT. Any information here may be revised at any time, and suggestions are more than welcome. Rev. #2017010401 (0.1.1) Abstract This draft defines the NNR (Network to Network Routing) protocol as part of the OCranet family of protocols. This document outlines how dynamic routing holds networks together in an NNR enabled OCranet network, how signalling is performed to control these networks, and the format of addressing used. This protocol is NOT the base protocol for OCranet networksand REQUIRES the support of specifications detailed in OETF #4; OCR (Ocranet Relay) protocol. Rationale The specifications detailed in OETF #4 only provide a means of cell forwarding for data networks and a robust topology. In the majority of cases it is not intended to be a stand-alone protocol. In a network of this type without any further support, only static routing can be achieved, requiring the manual configuration of connections along a path in a more permanent like manner. OETF #4 specifically and generously reserves a feature allowing us to control such a network beyond the boundries of its specification and is described in detail under section "Switches", sub-section "Services" in OETF #4. The specifications detailed in this document are built upon this feature, allowing a network to dynamically configure itself given little configuration by introducing 3 concepts called SIGNALLING, DYNAMIC ROUTING, and NODE ADDRESSING. Signalling Signalling is the concept of communicating with a network independent of other connections to receive information from, provide information to, or configure networks, usually in a pasive manner. with NNR, signalling becomes the heart of how an OCranet operates. All signalling in an NNR enabled network occurs on VPI 0, VCI 4. All signals are represented using 8 bit identifiers in a 1 byte header immediately following the VPI and VCI fields in an OCR cell. List of signal names and identifiers HELLO (0x01) Used by the active LOOP COORDINATOR to announce information about the network to newcomers. The information provided is as follows: (8 bits) The revision of the NNR protocol supported by the network (Currently 0). (128 bits) The Link Local address of the LOOP COORDINATOR (This provides the 16 bit Link Local prefix for local scope autoconfiguration)(48 bits) A 32 bit Network identifier and 16 bit Subnet identifier, if either is applicable (For global scope autoconfiguration) WHOIS (0x02) Sent by anyone to request if a particular address is in use. This can be an address of any type within the scope of the NNR addressing format [SEE BELOW]. If there is no response within 10 seconds of transmitting the WHOIS signal, then the address is considered up for grabs by the node which original sent the signal. The WHOIS signal is comprised as follows: (128 bits) The address being queried DEIFY (0x03) (Implementation currently optional) When no HELLO message has been received by the LOOP COORDINATOR for a given time, It is possible that the LOOP COORDINATOR has failed or disconnected for some reason. In this event, each switch with the same Link Local prefix count the entries in their routing tables for each virtual path, including their temporary cached entries and broadcasts a DEFIY signal on the loop. Though important for reliability, due to the complexities of this operation its implementation is currently optional. The DEIFY signal is comprised as follows: (128 bits) The link local address of the node they wish to become the new LOOP COORDINATOR INUSE (0x04) Broadcast message sent by a node witnessing a WHOIS broadcast with their Link Local address to inform the sender that the address is currently in use and active. The INUSE signal is comprised as follows: (128 bits) The address being queried in the WHOIS signal DIALOUT (0x05)(Forward recursive) unicast message sent to the LOOP COORDINATOR to request to build a circuit to the specified global scope address. The DIALOUT signal is comprised as follows (128 bits) The global scope address of the end node to reach (16 bits) A tag number passed back the LINE signal upon successful circuit construction informing the previous-hop / initiating node which connection is ready. This number can be anything, but should be unique within a short time frame at minimum. This number should be cached and changed at each hop as a security measure to prevent switches from becoming confused during circuit construction. (30 bytes) A host-dependent (Not covered in this document) data payload containing any information the end host needs to set up a connection. ACK (0x06) Unicast sent by any node acknowledging a signal from another node. This should be sent after any unicast message to prevent nodes from repeating themselves when signal reliability is necessary. The ACK signal is comprised as follows: (8 bits) The signal identifier being acknowledged. HUP (0x07) (Unidirectional/Multidirectional recursive) unicast message sent to the next-hop and/or previous-hop switch indicating to tear down / hang up the active circuit. This causes a recursive ripple effect that automatically tears down a connection. Any nodes in between that have not received the message should eventually time out and initiate an HUP signal themselves if applicable to fully dissassemble the circuit and prevent zombified links. If an HUP signal is not initiated at an endpoint node, then two HUP signals should be produced if applicable; One for the next-hop, and one for the previous hop. For security purposes, an HUP signal MUST ONLY be listened to if it arrives via the VPI & VCI pair it is associated with / forwards to. An HUP signal is comprised as follows: (8 bits) The Virtual Path Identifier in the direction of the teardown (16 bits) The Virtual Channel Identifier in the direction of the teardown LINE (0x08) (Reverse recursive) unicast message initiated from the end node providing all information the previous-hop needs to forward messages in a circuit to the next-hop toward the end node. The LINE signal is comprised as follows: (16 bits) The tag specified during the DIALOUT signal (16 bits) The VCI of the next-hop (8 bits) The VPI of the next-hop Addressing NNR uses a 128 bit address format that contains the following information: (16 bits) Address type (16 bits) Address parameters (32 bits) Network identifier (16 bits) Subnet identifier (48 bits) Host identifier A complete NNR address is represented in the following way: TTTT:PPPP:NNNNNNNN:SSSS:HHHHHHHHHHHH Where TTTT is the address type, PPPP is the address parameters, NNNNNNNN is the network identifier, SSSS is the subnet identifier, and HHHHHHHHHHHH is the host identifier. Address types Current, only two address types are supported. These are Link Local (0x0000), and Link Global (Address type 0x9001). Link Local addresses are unique within a loop and its next-door neighboring networks. The 16 bit parameters field in this case is called the "Local scope prefix" and provides a virtual barrier between networks on the same or adjacent loops. All nodes in the same local network share the same local scope prefix, but a switch bordering multiple networks may have more than one local scope prefix, and thus more than one link local address; One for local network group. Link local addresses are used solely for communicating within a local network group and can not be routed accross networks. A node with only a link local address has the added security of being globally invisible and unreachable without more complex routing infrastructure which is outside the scope of this document. Link Global addresses are unique for each network cluster (And MUST be unique within the entire OCranet scope). These addresses are used for communicating to nodes in neighboring or distant network loops. Shorthand formatting of addresses The subnet portion of global scope addresses is required to be present but may optionally used for routing [SEE SUBNETTING]. Likewise, the network AND subnet portions of a link local address are required but never used. For this reason, it is acceptable and RECOMMENDED to use the shorthand (double colon) operator when representing addresses for human readability. The double colon MUST only be used once in an address, and its position is dependent on the address type. A couple examples are provided below: The Link Local address 9001:0000:37f:0000:a8f35779fe4b can be shortened to this: 9001:0000:37f::a8f35779fe4b The Link Global address 0000:5f:00000000:0000:a8f35779fe4b can be shortened to this: 0000:5f::a8f35779fe4b Dynamic Routing In order for signals to operate, processes that fit in the category of dyanmic routing are necessary. These processes are as follows: New node joins a network loop Host NEWHOST is attached to a network loop. The procedure is as follows: NEWHOST waits for 20 seconds and listens for a HELLO signal or DEIFY signal. - If no signal is received, NEWHOST assigns itself a Local Scope prefix. This may be preconfigured or generated randomly. Use precaution when generating randomly to ensure that neighboring networks do not share the same prefix. It is much easier to just assign it manually when creating a new network loop for the first time. - If a HELLO signal is received, NEWHOST assigns itself the Local Scope Prefix of the LOOP COORDINATOR. - If a DEIFY signal is recieved, NEWHOST waits another 20 seconds and resumes from step 1. NEWHOST uses a UUID (It is RECOMMENDED to use the UUID of the OC network card in use if applicable) to generate a Link Local address using its Local Scope Prefix. NEWHOST sends a WHOIS containing the Link Local address it generated and awaits for an INUSE signal for 10 seconds. - If NEWHOST receives an INUSE signal with the Link Local address it generated, a new 48 bit host identifier must be generated. After this is done, resume to step 2. - If NEWHOST does not receive an INUSE signal with the Link Local address it generated within 10 seconds, it assigns itself that Link Local address. NEWHOST may optionally configure itself a Link Global address following steps 2 through 3 but instead using Link Global addressing. In the event that NEWHOST is a switch bordering another network and an existing LOOP COORDINATOR is available, NEWHOST sends a NEIGH signal containing a route to the network it binds to the LOOP COORDINATOR. This document may be a stub; It provides the majority of specifications for the NNR protocol but may be missing some specific features and will be updated within the near future.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.