ORACLE IMPLIMENTATION

Implementation

OCALA is implemented as a proxy that captures IP packets sent/received by legacy applications and relays them over the desired overlay network. This implementation currently works on Windows 2000/XP, Linux and Mac OS X, requiring no changes to the operating system.

Legacy applications identify overlay end-hosts using DNS-like names. These names usually consist of three parts: (1) the suffix which specifies the overlay type, (2) the middle part which identifies the overlay instance, and (3) the prefix which specifies the overlay-specific name. For example, foo.planetlab.i3, represents the host foo on the PlanetLab instance of i3 while bar.planetlab.ron represents the host bar running on the PlanetLab instance of RON. Provided with an overlay name ov_name.ov_inst.ov_type, the OC-I layer selects the OC-D module based on the overlay type (ov_type) and instance (ov_inst), and sends the overlay-specific name to (ov_name) to the OC-D module. The OC-D module resolves the overlay-specific name to an overlay identifier/address such as an i3 id. The OC-D layer can associate overlay-specific information to the overlay-specific name through a configuration file. For example, in an OverQoS overlay, we can use the configuration file to associate a target loss rate along the path to a given end-host.
1. Control Plane

The following figure illustrates the steps involved in establishing a new connection to an overlay host in OCALA.

Step 1 The legacy application issues a DNS request for foo.inst.ov, i.e., for host foo that resides on the instance inst of overlay ov.

Step 2 The OC-I layer captures this request and uses suffix inst.ov to identify the corresponding OC-D module. The OC-I layer then issues a tunnel setup request to the OC-D layer for the overlay-specific name, foo.

Step 3-4 The OC-D layer resolves foo to an overlay-specific identifier (IDB) using an overlay-specific resolution mechanism. For example, the i3 OC-D layer simply hashes the name to obtain the corresponding i3 id, while the RON OC-D uses DNS to resolve the name to an IP address.

Step 5 The OC-D layer initiates an overlay-specific protocol to set up a tunnel to the end-host identified by IDB. For example, in i3, setting up a tunnel involves negotiating and inserting a pair of private triggers by the two end-hosts. Similarly, in the case of HIP, setting up a tunnel involves authentication and establishing a secure channel between the two end-hosts.

Step 6 After setting up a tunnel, the OC-D layer returns a tunnel handle (tunnelAB) to the OC-I layer. This handle will be used by the OC-I layer to send packets via the tunnel.

Step 7-8 The OC-I layer now runs a path setup protocol. On successful completion, it returns a virtual (fake) IP address (IPAB) to the legacy application. This IP address belongs to an unallocated address space, e.g., 1.x.x.x. From the legacy application's point of view, this IP address represents the remote end point. From the OC-I layer's point of view, this IP address represents a handle to the state associated with the path to host B.
2. Data Plane

After the setup protocol described above is completed, the legacy application starts sending packets to the fake IP address returned in the DNS reply (IPAB). The following figure illustrates the data path operations.

Upon receiving a packet with destination IPAB, the OC-I layer on host A uses IPAB to identify the corresponding path (pathAB), and the tunnel to the next hop (tunnelAB). The OC-I layer adds the path identifier, pathAB to the packet header and sends the packet via tunnelAB.

On receiving the packet from the OC-I layer, the OC-D module at host A uses tunnel handle tunnelAB to retrieve the identifier of the destination, IDAB, and sends the packet over the overlay.

This packet is received by the corresponding OC-D layer at host B. The OC-D layer passes the packet to the OC-I layer. The OC-I layer uses the path identifier in the packet header to find the local handle (i.e., the IP fake address IPBA), strips off the OC-I header, and sends the packet to the legacy application at host B.

ORACLE OVERVIEW

Design

OCALA consists of an Overlay Convergence (OC) layer positioned below the transport layer in the IP stack. The OC layer bridges legacy applications and overlays by presenting an IP-like interface to legacy applications and tunneling the traffic of legacy applications over overlays. The OC layer is decomposed into the overlay dependent sublayer (OC-D), which interacts with the overlays, and the overlay independent (OC-I) sublayer, which interacts with the legacy applications:

The splitting of the OC layer into the OC-I and OC-D sub-layers enables OCALA to support simultaneous access to different overlays. The following figure shows an example in which three applications on host A open connections via IP and two overlays: a web browser (Firefox) uses IP to connect to www.cnn.com , a chat client (IRC) uses i3 to preserve the client's anonymity, and ssh uses RON for improved resilience.

The OC-I OC-D split also enables OCALA to easily support gateways that enable hosts connected to different overlays to communicate with each other. The following figure shows an i3 host communicating with a RON host via a gateway B.

The above figure also illustrates OCALA's notion of paths and tunnels. The OC-I layer creates and maintains an end to end channel, called a path, between two nodes that communicate with each other. A path can span multiple hops (as seen in the above figure), with forwarding information maintained at the OC-I layers of intermediate hops. The communication channel between two hosts at the OC-D layer is called a tunnel. A tunnel can be formed only between two hosts on the same overlay.

A tunnel can be constructed over regular IPv4/IPv6, and not only over new network architectures and overlays. Tunnels over IP enable hosts that do not run the OCALA software to communicate with OCALA-enabled hosts. Special OC-D modules, called legacy-server-IP (LSIP) and legacy-client-IP (LCIP) enable bridging between regular IP and new network architectures. Figure (a) below illustrates an OCALA-enabled host communicating with a legacy server (www.nasa.gov), while Figure (b) shows a legacy client communicating with an OCALA-enabled server.

C Graphics 2

#include
#include
#include
#include
void dda(float x1,float y1,float x2,float y2)
{
float dx,dy,x=x1,y=y1,m;
int i;
dx=x2-x1;
dy=y2-y1;
if(abs(dx)>=abs(dy))
m=abs(dx);
else m=abs(dy);
putpixel((int)x,(int)y,15);
for(i=1;i<=m;i++) { x=x+dx/m; y=y+dy/m; putpixel((int)x,(int)y,15); } } void bress(float x1,float y1,float x2,float y2) { int x,y,end,inc=0,p,dx=abs(x2-x1),dy=abs(y2-y1),c=0,current=0; if(dx>dy)
{
p=2*dy-dx;
if(x1y2)inc=-1;
}
else
{
x=x2;y=y2;end=x1;
if(y2y1)inc=-1;
}
while(x<=end) { putpixel(x,y,15); if(p<0) p=p+2*dy; else { y=y+inc;p=p+2*(dy-dx); } x++; if(current==0&&c==10) { current=1;c=-1; } if(current==1&&c==6) { current=0;c=-1; } c++; } } else { p=2*dx-dy; if(y1x2)inc=-1;
}
else
{
y=y2;x=x2;end=y1;
if(x2x1)inc=-1;
}
while(y<=end)
{
putpixel(x,y,15);

if(p<0)p=p+2*dx;
else
{
x=x+inc;p=p+2*(dx-dy);
}
y++;
if(current==0&&c==10)
{
current=1;c=-1;
}
if(current==1&&c==6)
{
current=0;c=-1;
}
c++;
}
}
}

void main()
{
float x1,x2,y1,y2;
int ch;
int gd=DETECT,gm=DETECT;
initgraph(&gd,&gm,"");
printf("Enter end points of line(x1,y1,x2,y2)");
scanf("%f%f%f%f",&x1,&y1,&x2,&y2);
printf("Choose Algorithm(1-DDA 2-BRESENHAM)");
scanf("%d",&ch);
if(ch==1)
dda(x1,y1,x2,y2);
if(ch==2)
bress(x1,y1,x2,y2);
getch();
closegraph();
}

C Graphics

#include
#include
#include

void main(){
int graphdriver = DETECT, graphmode;
initgraph(&graphdriver, &graphmode, "..\\bgi");
circlel(250, 100, 25);

getch();
closegraph();
}