rina java prototype demo and development...

RINA Java Prototype demo and development plans

PhD Course on Future Network Architectures and Experimentation

University of Kaiserslautern, March 7th, 2012

Miguel Ponce de Leon, TSSGJohn Day, Boston University

Eduard Grasa, Fundació i2CAT

Outline

RINA Adoption strategy and current prototype rationale

Prototype implementation phases

Prototype description

Demo

2

RINA Adoption strategy

Start as an overlay to IP, validate technology, work on initial concepts, develop DIF machinery. Useful by itself: internetwork layer(s), decouple application from

infrastructure, improved application API, support for multi-homing and mobility.

TCP/IP or UDP/IP

Ethernet

Physical Media

Applications

UDP/IP

Ethernet

Physical Media

Applications Ethernet

Physical Media

Applications

DIF

DIF…

DIF

DIF…

Physical Media

ApplicationsToday

DIF

DIF…

TCP/IP or UDP/IP

Physical Media

Applications

DIF

DIF…

End goal

Current PSOC

prototype

3

RINA over IP benefits: Internetwork layer(s)

What if application A wants to communicate with Application C? It cannot do it, unless you start deploying middleboxes like NATs, application-layer gateways,

… The architecture doesn’t accommodate internetworking!

4

! ! !

Data Link Data Link Data Link Data Link Data Link

IP

IP Network A (Public Internet)

IP

IP Network B (Enterprise Network)

TCP

Appl. A Appl. B Appl. C

! ! !


IP


IP


DIF


DIF

DIF

RINA over IP benefits: Separate applications from infrastructure

The current application namespace is tied to IP addressing and TCP/UDP port numbers:

This makes mobility hard to achieve In RINA applications have names that are independent of the

layers below (DIFs) Application names can be structured in a way that makes sense

for the application The application name doesn’t contain the semantics of where the

application is in the network (i.e. what is its point of attachment to the layer below) 5

http://pouzinsociety.org

Synonym of an interface of a host

Socket (Endpoint of TCP connection)

:80

RINA over IP benefits: Next generation VPN

DIFs are customizable VPNs that can span multiple IP networks. Each DIF has its own addressing scheme, security mechanisms (authentication,

authorization), routing strategy, resource allocation strategy (support for different levels of QoS), flow control strategy, data transfer/data transfer control, …

Processes (and not systems) are members of the DIFs (different processes can access different DIFs in each system). Processes may not have access to the whole range of DIFs available on their system

DIFs open the door to VPNs optimized for certain applications

6

! ! !


IP


IP


DIF


DIF

DIF

Outline




Demo

7

Architectural model

DIF

System (Host)

IPC Process

IPC Process

MgmtAgemt

System(Router)

IPC Process IPC Process

IPC Process

MgmtAgemt

System(Host)

IPC Process

IPC Process

MgmtAgemt

Appl. Process

DIF DIF

Appl. Process

IPC API

Data Transfer Data Transfer Control

Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection

Transmission Control

Retransmission Control

Flow Control

RIB Daemon

RIB CDAP Parser/Generator

CACEEnrollment

Flow Allocation

Resource Allocation

Forwarding Table Generator

Authentication

State Vector

State Vector

State Vector

Data Transfer Data Transfer





Flow ControlFlow Control

8

IPC Resource Mgt.

Inter DIF Director

y

SDU Protection

Multiplexing

IPC Mgt. Tasks

Other Mgt. Tasks

Application Specific Tasks

IP Network A

Implementation phases

IP Network

IPC Process IPC ProcessDIF

Appl. Process

Appl. Process

A) Two systems directly connected through a single IP Network (demo)

IP Network

B) N systems directly connected systems through a single IP

Network(in 1 month)

IPC Process

Appl. Process

IPC Process

Appl. Process

Appl. Process

TCP flowDIF

IPC Process

TCP flows

IP Network B

C) N systems connected through multiple IP

networks (end of 3Q)


IPC Process

IPC Process


IPC ProcessDIFDIF

DIF

Appl. Process

Appl. Process

UDP flow UDP flow

9

Phase I: 2 systems direct

IP Network

IPC Process IPC ProcessDIF

Appl. Process

Appl. Process

TCP flow

IPC API


Layer Management

SDU Delimiting

Data Transfer


SDU Protection



Flow Control

RIB Daemon


CACEEnrollment

Flow Allocation

Resource Allocation


Authentication

State Vector

State Vector

State Vector







The following IPC Process components have to be developed: SDU Delimiting, RIB, RIB Daemon, CDAP,

CACE, Enrollment, Flow Allocation, IPC API Enrollment and Flow Allocation implemented

10

IPC Resource Mgt.

Inter DIF Director

y

SDU Protection

Multiplexing

IPC Mgt. Tasks

Other Mgt. Tasks


The following IPC Management (OS) components have to be developed Trivial IRM (create, destroy, list IPC Processes), Static IDD (config file)

Phase 2: N Systems direct

IP NetworkIPC Process

Appl. Process

IPC Process

Appl. Process

Appl. Process

DIFIPC Process

TCP flows

IPC API


Layer Management

SDU Delimiting

Data Transfer


SDU Protection



Flow Control

RIB Daemon


CACEEnrollment

Flow Allocation

Resource Allocation


Authentication

State Vector

State Vector

State Vector







Changes with respect to phase I: Complete implementation of enrollment and

flow allocation. A dynamic, but very simple IDD (just suitable

for small groups of DIFs)

11

IPC Resource Mgt.

Inter DIF Director

y

SDU Protection

Multiplexing

IPC Mgt. Tasks

Other Mgt. Tasks


Phase 3: N systems not directly connected

IP Network A IP Network B


IPC Process

IPC Process


IPC ProcessDIFDIF

DIF

Appl. Process

Appl. Process

UDP flow UDP flow

IPC API


Layer Management

SDU Delimiting

Data Transfer


SDU Protection



Flow Control

RIB Daemon


CACE

Enrollment

Flow Allocation

Resource Allocation


Authentication

State Vector

State Vector

State Vector







Changes with respect to phase II: Implementation of EFCP

(DTP and DTCP), the RMT and the routing component

Authentication, Resource allocation and SDU protection may be out of the scope of the initial prot.

12

IPC Resource Mgt.

SDU Protection

Multiplexing

IPC Mgt. Tasks

Other Mgt. Tasks


Inter DIF Director

y

Outline




Demo

13

Prototype description Implemented as part of the TINOS framework (a network

protocol experimentation framework) https://github.com/PouzinSociety/tinos

Implemented in Java, using the OSGi technology (OSGi container provided by the Eclipse Virgo container) OSGi is a component model that facilitates building modular Java

applications

Tested on Mac OS X and Linux Debian, but should be multi-platform (support all the platforms that Eclipse Virgo supports)

Not yet fully integrated with TINOS (once it is, it will be possible to instantiate several “systems” within a single Java process, using XMPP as the underlying “physical substrate”) 14

https://github.com/PouzinSociety/tinos

https://github.com/PouzinSociety/tinos

Current structure

15

Virgo Server

IPC Manager

ConsoleService

Listen for local TCP connections at port 32766

Application Service IPC Process Lifecycle

Management (“IRM”)

Listen for local TCP connections at port 32771

Client Application 1RINA Lib

For each flow, local TCP connection to port 32771

Server Application 1RINA Lib

For the registration, local TCP connection to port 32771 Listen for local TCP connections at

port X (dynamically assigned)

For each flow to service application 1, local TCP connection to port X

IPC Process

Components

IPC Service

Delimiter

RIB Daemon

RMT

Encoder CDAP Session Manager

Flow Allocator

Enrollment Task

Listen for TCP connections at port 32770

Listen for TCP connections at port 32769

Local administration

IDD

Outline




Demo

16

Internet

Demo scenario

Two systems, with one IPC process each (red circles). One system (left) is running the client application, the other

system (right) an echo server application (echoes strings back). What works: IPC process creation, enrollment, flow allocation,

application interfacing through native RINA API Now have to verify interop with Steve and Peter’s prototype, as well as with

BU’s prototype.

84.88.40.23

84.88.41.36

AP Name: i2CAT-

BarcelonaAP Instance: 2

Address: 2

AP Name: i2CAT-


Address: 1

RINA-Demo.DIF

AP Name: /rina/examples/apps/

cliClient


echoServer

22

17

System ASystem B

Internet

1) Instantiation of the IPC processes

18

84.88.40.23

AP Name: i2CAT-

BarcelonaAP Instance: 2Address: null

84.88.41.36

AP Name: i2CAT-


Address: 1

RINA-Demo.DIF

SSH into system A, start the Virgo container, and connect to the management console. Then create IPC Process i2CAT-Barcelona 1 as the single member of the DIF RINA-Demo.DIF

SSH into system B, start the Virgo container, and connect to the management console. Then create IPC Process i2CAT-Barcelona 2; not belonging to any DIF

System ASystem B

2) Common application Connection Establishment

19

Internet84.88.40.23

AP Name: i2CAT-


84.88.41.36

AP Name: i2CAT-


Address: 1

RINA-Demo.DIFSystem ASystem B

TCP flow

1

3

M_CONNECT

M_CONNECT_R2 Authenticate

SSH into system B, connect to the management console, and tell IPC Process i2CAT-Barcelona 2 to enroll to IPC Process i2CAT-Barcelona 1 First it will allocate a TCP flow to i2CAT-Barcelona 1, then it will go

through CACE (Common application connection establishment) and finally through the enrollment program

3) Enrollment

20

Internet84.88.40.23

AP Name: i2CAT-


84.88.41.36

AP Name: i2CAT-


Address: 1


TCP flow

1

2

M_READ( address)

M_READ_R (address)

3Address is null, wait for M_READ (enrollment)4

5

M_READ

M_READ_R

5M_READ_R

. . .

6

7

M_START (opStatus)

M_START_R (opStatus)

Internet84.88.40.23

84.88.41.36


TCP flow

AP Name: i2CAT-


Address: 2

AP Name: i2CAT-


Address: 1

Internet

4) Instantiation of the Server application

21

84.88.40.23

AP Name: i2CAT-


Address: 2

84.88.41.36

AP Name: i2CAT-


Address: 1

RINA-Demo.DIF

SSH into system A, start the Java echo server application. It will register to the RINA-Demo.DIF, making itself available through this DIF.

System ASystem B


echoServer

Internet

5) Instantiation of the client application, and allocation of flow

22

84.88.40.23

AP Name: i2CAT-


Address: 2

84.88.41.36

AP Name: i2CAT-


Address: 1

RINA-Demo.DIF

SSH into system B, start the Java echo client application and tell it to connect to the echo server application. It requests a flow to the echo server application by name (/rina/examples/apps/echoServer)

System ASystem B


echoServer


cliClient

22

Thanks for your More information about the prototype at

https://github.com/PouzinSociety/tinos/wiki/RINA-Prototype

rina java prototype demo and development...

Documents