merge RFCs from multi repos to this one >>

- Change PersiaDB to Ganjine
- Change UIP to GP
- Change Switch to Chapar
- Change ChaparKhane to Acheamenid and use ChaparKhane for other purpose
- Some Imporvments and fixes!

Achaemenid.md

@@ -0,0 +1,78 @@
+# Achaemenid - Server
+The same when we write a letter, we don't think about how it will be delivered, Achaemenid used to think & design digital platform services locally by almost know related architecture like [SOA](https://en.wikipedia.org/wiki/Service-oriented_architecture) or [Microservices](https://en.wikipedia.org/wiki/Microservices) or [ServerLess](https://en.wikipedia.org/wiki/Serverless_computing) or NanoServices or [FaaS](https://en.wikipedia.org/wiki/Function_as_a_service) and let Achaemenid make runtime and do other things for your networking!! Result of Achaemenid is a runnable monolithic app that can do every thing for you such as authentication, authorization, routing, logging, ... in most efficient way! So Achaemenid [autogenerate](https://en.wikipedia.org/wiki/Automatic_programming#Source-code_generation) multi network handler for written services logic in specific template [like this](https://github.com/SabzCity/sabz.city). It will also make SDK in multi language for client usage.
+
+## Supported Protocol
+All information get from [IANA Resources](https://www.iana.org) like [IP Protocols](https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml), [Transport Protocols](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml), ... But we don't support all of them now and some will never support due many problem in their architecture. Also we introduce new whole [network](./Giti.md) with lot of improvement in privacy and performance!
+
+### GP - Giti Protocol
+- Each Application lease 16bit range GP from OS router!
+- Developers can choose to respect the whole packet structure or just the first 256 byte used for routing and change other structure as a requirement!
+
+## Supported usage!
+Achaemenid implementation must support at least three way as:
+- API As a Service : Call needed service functions (APIs) from generator repository(folder).
+- Version Controls : Part of CI/CD process like tests codes!
+- CLI : Call needed API by user friendly commands!
+
+## Rules
+To write better business logic read these advices! A lot of way exist to handle service versions like  [Git Basics - Tagging](https://git-scm.com/book/en/v2/Git-Basics-Tagging), [Semantic Versioning](https://semver.org/) But we decide very innovative way explain below.
+
+### Folders
+Folders use just to group same logic platform services API. In `apis` folder of platform repository you must have `services` and inside it you can have as many as you need hierarchical folder tree to group services together!
+
+### Services
+You must follow this rules:
+- Split each service (exported or public function) in one file to appreciate NanoService pattern! Never include more than one service in a file!
+- Always make and complete ServiceDetail structure by server manifest rules!
+- Achaemenid respect given ID by you to services indicate in ServiceDetail! But if it is empty(0) it will calculate it from hash of ServiceName! Due to hash collision, maybe force you to change ServiceName or indicate ID handy!
+- Don't delete unneeded services files, just change related ServiceDetail like ExpireDate and status! and never ever use old service name for new service with different service structure!
+---- SO DON'T REUSE OLD ID EVEN IF YOU DON'T NEED THEM EVER! ----
+- You can change service structure before you indicate service is StableRelease in ServiceDetail! So don't changed it after it, Always make new service if you want change service structure by for example add `V1` to end of service name and dedicated file e.g. `register-new-person-v1.go`!
+- As always use full detail name for service names(function). You can add random or specific ID to end of service name for reusability of that name.
+
+### DataStore layer:
+- It is better to have separate folder e.g. `datastore` for data layer architecture!
+- Just call owner data store in each service and call other service function if need others data!
+
+### Prohibited
+- Autogenerated code should not be edited, since it may be automatically overwritten by the same process.
+
+## Architecture details
+
+## Security
+- Everything only can run in security protocol like TLS. we force redirect http to https requests.
+
+## Compress
+To achieve better bandwidth we force to compress request and answer. e.g. gzip
+
+## Management and analitics
+
+## Logging
+
+## Caching
+We just cache HTTP GET method. we must work to cache other get method.
+
+## AI
+### Security
+- [Quic Security Considerations](https://tools.ietf.org/html/draft-ietf-quic-transport-16#section-21)
+- Track multi broken stream as kind of attack.
+- Track for try to open multi guest connections. guest user can just one connection per IP.
+- Track for stream fragmentation and reassembly attacks.
+- Track for changed IP more than twice in little time! It may connection information had been leaked!
+
+## Done in autogenerate layers
+- Serialize and deserialize data format like json, xml, binary, ... would be faster up to 5x because of not use of reflection   
+  e.g. https://github.com/mailru/easyjson , https://github.com/pquerna/ffjson
+- Check & validate request data
+- Make handlers to receive data and call service functions.
+- Make API documentation in many standards e.g. OpenAPI(Swagger), ...
+- Make SDK in multi language & system e.g. Go, TS, ...
+
+## Implementations
+- [Go](https://github.com/SabzCity/libgo/Achaemenid)
+
+## Inspired of
+- http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
+
+## Achaemenid word meaning
+["Achaemenid"](https://en.wikipedia.org/wiki/Satrap) (Persian: ساتراپ) were the governors of the provinces of the ancient Median and Achaemenid Empires and in several of their successors, such as in the Sasanian Empire and the Hellenistic empires

Chapar.md

@@ -0,0 +1,48 @@
+# Chapar - Data Link Protocol
+A real stateless switching protocol! This protocol can transmit frames in almost speed of physical layer limiting! It is all about improve [layer 2 of OSI](https://en.wikipedia.org/wiki/Data_link_layer)! The introduced [switch design](https://en.wikipedia.org/wiki/Stateless_protocol) isn't like Ethernet switch that must store MAC address state in each switch and will switch frames in [stateless manner](https://en.wikipedia.org/wiki/Connectionless_communication).
+
+## Ethernet disadvantages
+- High price & have limit to make layer 2 network without get help from layer 3! The best switch have up to 512000 TCAM record limit for query MAC to the port!
+- High power usage and limit speed in TCAM tables!
+- Close source complicated hardware and switching algorithms!
+
+## Goals
+- Decrease switch products & network price
+- Improve network bandwidth & latency without increase networking price!
+- Make big layer 2 network as 256^256(2^2048) node without need upper layer!!
+- Make networking greener by reduce direct(switch devices) and indirect(cooling) power usage!
+
+## Not Goals
+- Security : Layer 2 is more related to physical layer network that need physical security to eliminate access a device from desire network! So security of a network must handle in upper layer than layer 2.
+- Error detection : Due to simplicity of protocol and quality of todays hardwares it is better to check healthy of data just in destination not in every switch device!
+
+## Still considering
+- Still need cache on ports! Frames congestion that force use cache on ports interfaces can drop up to 50% efficiency!
+
+## Packet architecture
+- StartDelimiter, EndDelimiter & CheckSequence may add to this structure due to physical layer rules!
+- Ports number can be mutable due to physical links limits. Endpoint must beware of this aspect!
+- Each switch interface in any location of link can be wire or wireless with any Energy||Frequency specs (e.g. Fiber, WiFi, LAN, Bluetooth, ...)
+
+| bits  | data type                 |
+| :---: | :---:                     |
+| 0     | Next Hop                  |
+| 8     | Total Hop                 |
+| 16    | Next Header               |
+| 24    | Switch 1 PortNum          |
+| ...   | Switch x PortNum(Optional)|
+| ...   | Payload                   |
+
+- Next Hop : Indicate switch port number use on next switch device!
+- Total Hop : Total hop numbers and also indicate payload location!
+- Next Header : Indicate upper layer protocol equal EtherType!
+- Switch 1 PortNum : Source Port Number, also can be Destination Port Number in P2P(Point to Point) connection.
+- Other Ports : Up to 256 switch port number can be here in frame!
+- Payload : Up to 8192 Byte or 8KB. Enough to stream 1.5Mbps video call in each 40ms frames (1.5/8*1024/1000*40=7.68KB)
+
+## Inspired of
+- https://guifi.net/
+- https://en.wikipedia.org/wiki/Telephone_exchange
+
+## Chapar word meaning
+["The Chapars"](https://en.wikipedia.org/wiki/Chapar_Khaneh) (Persian: چاپار‎) were express couriers who were provided with fresh supplies and horses at each station along the way, allowing them to quickly complete their way without having to procure supplies on their own or wait for their horse to rest.

ChaparKhane.md

@@ -0,0 +1,17 @@
+# ChaparKhane - Router Server
+ChaparKhane use to be gateway and route [GP protocol](./GP.md) packets inside XPs or to other XPs! ChaparKhane can also be as coordinator in networks without need GP packets come to ChaparKhane to route!!
+
+## XP - Exchange Point (similar to IXP)
+- Each XP can have many GP Router with multi path data-link connection! that has two type connection
+    - Connection to same XP routers to route income or outcome frames.
+    - Connection to one or more other XP Routers with direct or tunnel physical links by using other XP links! Tunnel connections are optional and just for decrease latency due to less frame or packet routing needed!
+- Routers must broadcast any change to data-link address to the shared database!
+- Each XP obtain just one unique 32-bit unsigned integer for routing in its database and tell all adjacent physical connected XPs about existence! So XP can just register a 32-bit address just if it has a direct link to some other XPs.
+- We must rule to make XPs network grows slowly.
+
+## GP Routers (similar to ISP)
+- Each 32bit range GP (as max apps can lease GPs) has a public key that generates in negotiated by XP and App router(owner of GP).
+- Each GP packet encrypts in OS and App layer by paired EncryptionKey before sending. This way no GP Address can steal by others!
+
+## ChaparKhane word meaning
+["Chapar Khaneh"](https://en.wikipedia.org/wiki/Chapar_Khaneh) (Persian: چاپارخانه‎, IPA: [tʃɒːˈpɒːɾ xɒːˈne], courier-house) is a Persian term for the postal service used during the Achaemenid era. The system was created by Cyrus the Great, the founder of the Persian Empire, and later developed by Darius the Great, as the royal method of communication throughout the empire. Each "Chapar Khaneh" was a station mainly located along the Royal Road, a 2500 km ancient highway, which stretched from the Sardis to Susa, connecting most of the major cities of the empire.

GP.md

@@ -0,0 +1,76 @@
+# GP - Giti (Network) Protocol
+We combine OSI layer 3 to layer 6 requirements as Network + Transport + Session + Presentation protocols to have one protocol and remove all overhead data. This protocol needs in the IoE era (Internet of Everything) for connecting things, people, data, ...!
+It has some differences in internal service call, security, pipelining, multiplexing, ... . It will introduce huge advantage and improve app network performance! We will implement this protocol in [PersiaOS](./PersiaOS.md).
+
+## IP disadvantages
+- IP Routers can just be gateway!
+- Registering system is centralized and manual human base!
+- IP leases fee is high!
+- IP addresses can't (or very hard to) register by end user and usually register by ISP!
+- IP addresses can't prove their ownership to use in authentication process due to above problem!
+- IP address can easily spoofing! Spoofing can be used as part of a DoS attack and Can't determine source of attack!
+
+## Goals
+- Decentralized and automatic process to register routers in any layer!
+- Free, automate and floating to lease new GP address!
+- Make GP routers as coordinator in network along side be a gateway!
+
+## Still considering
+- How and when to allow new XP register in XP networks!
+
+## Packet Architecture
+| bits          | Length(byte-Octet)| data              |
+| :---:         | :---:             | :---:             |
+| 1 ... 128     | 16                | Destination GP    |
+| 129 ... 256   | 16                | Source GP         |
+| 257 ... 272   | 2                 | Payload Length    |
+| 273 ... 304   | 4                 | Stream ID         |
+| 305 ... 336   | 4                 | Packet ID         |
+| 337 ... __    | __                | Payload           |
+| __            | __                | Padding           |
+| __            | __                | Checksum          |
+
+- **Payload Length** : Always encrypted and must respect data-link protocol due to not Fragmentation supported. Better not over of 8192 Byte(octets) or 8KB! Not include headers, padding or checksum!!
+- **Stream ID** : Always encrypted. Use even number for client(who start connection) to start a stream e.g. 0,2,4,6,8,10,... . Use odd number for server(who receive connection) to start a stream e.g. 1,3,5,7,9,11,... 
+- **Packet ID** : Always encrypted. Max 4.72TB can transmit in single stream with 1.18KB payload Length as limit to 1.5KB of ethernet frames! 
+- **Payload** : Always encrypted, Payload can be any application protocol e.g. HTTP, sRPC, ... . It must store in order by PacketID to make whole a stream data
+- **Padding** : If block cipher use, add some random data to have fix size packet!
+- **Checksum** : Depend on mode it use to authenticate data transmitted and check packet healthy!
+
+### Extended header
+It introduces an internal service call instead of data in each header!
+
+### Versioning
+Unlike existing Internet Protocol as IP, we don't offer any versioning for this protocol as we believe if we need fundamentally change any part of a protocol after the official release, we will already make new protocol! So we respect data link layers protocols like Ethernet and use their solution like [Ethertype](https://en.wikipedia.org/wiki/Ethertype) in [Ethernet frame](https://en.wikipedia.org/wiki/Ethernet_frame) header and don't reinvent other solution!
+
+## GP Address
+GP address lengths is 128 bit(16 byte) that contain 32+32+32+16+16bit as XPs + GP Routers + OSs + Apps + Protocols!
+This protocol unlike IPv6 regard each bit of a GP address. We suggest use below rules but just XP part must always respect these rules and each XP network can have own rules about routing protocol in their networks!
+- **XP(Exchange Points)**: *0 to 31 bit* >> *32bit length* >> Each civilization like exiting country can tell others and get a 4 byte unique immutable identifier. We know some considering exist and we must have some rules to allow new members in XPs!
+- **Routers**: *32 to 63 bit* >> *32bit length* >> Each XP must delegate its range to some routers to do routing for improve performance & consistency of its own network. So each Router always have 4 byte unique mutable identifier.
+- **Users**: *64 to 96 bit* >> *32bit length* >> Each user on each device can get 4 byte unique mutable identifier from router. This range usually get by OS and route them to register app by user in OS. So an OS can host one or more users!
+- **Apps**: *97 to 112 bit* >> *16bit length* >> Each user app can get 2 byte unique mutable identifier from OS. Same app but for different user always get dedicate unique range.
+- **Protocol**: *113 to 128 bit* >> *16bit length* >> Each App have 2 byte address range that usually use to detect payload data structure some thing like TCP||UDP port number purpose!
+
+## Routing Architecture
+
+### Mobile GP
+The [Mobile GP](https://en.wikipedia.org/wiki/Mobile_IP) allows for location-independent routing of the GP packet on the Internet! We don't have rules for mobility implementation in this spec! You can achieve mobility just by have proper topology in your XP and data link layer!
+
+### Quality of Service
+It must be handled in routers, not protocol packet!
+
+### Local Network
+When no GP router exists in a network, Nodes can set the first 64bit of GP to zero and broadcast their-selfs to each other!
+
+### Multi-cast & Any-cast
+Due to the nature of this spec that must be decentralized, and we believe this type of requirement must handle at the app layer to protect user privacy, So we don't offer any way to multi-cast or any-cast a packet in Giti networks!
+
+## Supported programming languages
+It is so simple protocol that can easily encode and decode in any programming language! We implement it on some language like [C](), [Go](https://github.com/SabzCity/libgo/blob/master/GP), [JavaScript]() and more in progress ...
+
+## Inspired of
+- [QUIC](https://en.wikipedia.org/wiki/QUIC)
+- [IPv6](https://en.wikipedia.org/wiki/IPv6)
+- https://www.semanticscholar.org/paper/Blockchain-models-for-universal-connectivity-Navarro-Castro/788b7a634b369d98e72ed37c5fdf71f7fd62ef0b
+- https://pdfs.semanticscholar.org/788b/7a634b369d98e72ed37c5fdf71f7fd62ef0b.pdf?_ga=2.260489549.1562006812.1569054619-1995410782.1569054619