• Mission

    We are a RINA Users Group (RUG) in Japan. We are currently working with sponsorship from a communications service provider in Japan. We have weekly meetings to discuss the deployment challenges of RINA. The problems we solve are in preparation for a commercial RINA launch.

    Key Performance Indicators

    1. Solve the dynamic namespace management, enrollment, flow allocation, resource allocation, routing, and security issues with a recursive taxonomic namespace service. All RINA stacks publicly available use static namespace management.

    2. Realize a commercial RINA deployment in Japan between two datacenters using ethernet / WDM before February 2021.

    3. Deploy a Cardano ADA staking host and relay nodes on the RINA network using IP over RINA by March of 2021.

    4. Work with the Cardano community to test and eventually upgrade the IP over RINA to Ouroboros over RINA using ethernet / WDM sans IP.

    5. Continuously promote and develop commercially viable RINA solutions and deployments.

    Our Sponsor

    GLBB Japan

    Innovative communications service provider in Japan. www.glbb.jp



  • FAQ

    RINA is a router at every IPC so the question is a bit hard to orientate but will assume you mean are any open source stacks available for existing equipment and “Yes” with some challenges. Implementation on existing routers using RFC7426 seems the best option at this point even using Network Function Virtualization is an option with this SDN example.

    Yes. For example we have questioned the wisdom of how some things are done and we do plan to experiment. Once we have verified our experiments we will release for peer review and open source is the way we plan. We are planning to contribute 802.2 ethernet shim for example and it is an open milestone for the IRATI project if they will allow it.

    A RINA shim into the ethernet is just a gateway as a host to the IPv4/v6 cloud. Then the RINA host is seen in the BGP world as just a TCP/IP flow. RINA itself does not need these protocols, single destination, single source view of the tree with Dykstra Shortest Path First simplicity is enough but I would like to see flexible routing policies per IPC. Personal experience says when BGP next hops are routed over OSPF that is running over ISIS say over 802.1ah/802.1aq shortest path bridging is that you only need to play with one of those knobs to achieve your traffic engineering goals.

    TCP/IP is insecure and cannot scale. RINA can scale and is secure by nature. We need scaling due to the need to run private and public connections over one network that nowadays includes an internet of things. Core routers at service providers today have almost 850,000 best IPv4 routes and the IPv6 table is almost 100,000 routes already! These best routes are boiled down from peer routes all stored in the routing information base. After all this work, nobody can map a name to an address because another trusted 3rd party, DNS, is needed. This is centralized routing and naming. RINA will prioritize naming and deprecate the concept of global addressing. Addresses are not even needed on point-to-point links. Routing is done to a taxonomy and not to an address. Your address is private between the directly connected parties. RINA also brings the noise level of the internet way down as port scans and such will cease to a halt.

    We will use the Viavi TB-5800-100G to discern our performance locally sans RINA with L1 BERT testing. After that we will test with RINA and some special tests we are planning. Once we know we have a working solution we do plan to connect a RINA node to a RINA node over our redundant 10G connections between LA and Tokyo.

    Existing protocols also assume too many errors and the largest Ethernet MTU’s are not more than 10K bytes, usually 9,000 to 9,600 bytes are maximum transmission unit for PDU’s over ethernet jumbo frames, RINA can get a lot more data through a flow in larger frames. Having an adjustable frame size only make sense nowadays as a normal enterprise 10G ethernet circuit is usually tested clean at line rate for 24 hours before putting into service. This means that the message can be in very large packets rather than broken into many small frames. I do not know the MTU that native RINA will settle but I suspect it to be much higher default than existing ethernet.

    Our experimentation is focused on the wired-line and not 5G. Generally speaking from the ISP business we are not seeing any decrease in demand for smoking fast fiber connectivity. Latency is going to be dependent on the bits required to encode the data. We know there are folks working with a Canadian provider to implement a RINA architecture but it is really not our project.

    Yes, one of our many RINA projects focuses on how to RAMP up a network! We hope to talk abut this more in the future

    Our proposal is for RINA to ride over IP so nothing needs replacement. We feel the accountants will win in the end. One example is with MPLS. Recently, technologies like VXLAN are shredding MPLS in the market. Is RINA not the same? Like ZeroTier, could one use RINA and say 802.2 SNAP frames with RINA to expand the IPv4 address space by 24 bits of OUI (in the SNAP frame header?) Our proposal is to have fun and experiment and learn the answers to your questions as we surf the real commercial market opportunities. The RUG is not in charge of the project. This is a real R&D project already funded. The RUG is there to focus on use cases for the network.

    I think our RUG in Japan would want a RUG at that distant location or for that location to be under a network under 100% control so we can have exact telemetry. Distance is one thing to consider of course and in the connectivity business all you need is enough trust to establish a flow. We are very open to things especially considering the phased approach to the Catalyst funding by Cardano where perhaps we can fund other RUGs that have local RINA enclaves. I think this week our RUG meeting will discuss making a video to introduce ourselves to the community.

    It would be seemless as it would be a migration from IP. We would hope when a Cardano node sees an IP interface it acts like IP and when it sees a RINA interface perhaps a RINA shim over ethernet / ip that it acts like RINA. Ethernet framing is really unnecessary for RINA so we are hoping we can develop Ouroboros directly over RINA for the future.

  • Leave a contact request