ST JOSEPH’S AUTONOMOUS

COLLEGE

Future Internet Design (FIND) Architectures: Using eXtensible

Session Protocol

BY

AGUGHASI VICTOR IKECHUKWU (14MCS6401)

 ST JOSEPH’S AUTONOMOUS
COLLEGE

Future Internet Design (FIND) Architectures: Using eXtensible

Session Protocol

BY

AGUGHASI VICTOR IKECHUKWU (14MCS6401)

 application interfaces in the network
Agughasi Victor Ikechukwu [14MCS6401] ecosystem. While there is no unified approach
Department of Computer Science to session layer functionality in the current
St. Joseph’s College (Autonomous) Langford Internet, there are many in-stances of
Road, Shantinagar, Bangalore-560027, India. functionality that is consistent with a session
victor.agughasi@gmail.com layer. XSP is conceptually related to the ITU-T
Recommendation X.225 connection-oriented
Abstract session protocol specification [1], which
Dealing with modern heterogeneous network defined “a single protocol for the transfer of
technologies in a simple, uniform manner has data and control information from one session
become an increasingly difficult challenge. To entity to a peer session entity between
help address this issue, I analysed a session systems which support the session layer of the
layer protocol called the eXtensible Session OSI reference model.” The essence of this
Pro-tocol (XSP) designed to integrate existing approach is simply that the session layer lives
network sys-tems, providing the ability to above the transport layer, and provides proto-
easily introduce additional protocol col encapsulation for both control and data
functionality as needed, including application- protocol units. This model then subsumes
driven network allocation and integration with cases like SIP, where the protocol control
network “middleboxes.” The XSP information is exchanged out of band, with the
implementation is currently tar-geted at data encapsulation being essentially null at
network middleware architectures where it the session layer and using e.g. RDP at the
allows for the transparent integration and transport layer. It also ex-presses the DTN
configuration of new and existing network “bundling” approach by including both control
components and services. and data parts in the PDU.

Keywords: The focus of this journal is on two

additional use models. The first is on the use
eXtensible, Protocol, Architectures, Session,
of performance oriented “middle-boxes”, which
Layers, OSI Reference Model, Networks,
in the session paradigm are simply gate-ways.
Applications
These middleboxes and can act as
“accelerators” and mitigate performance
I. Introduction problems over long distance, high speed
The aim is to present the eXtensible Session networks. The second use of XSP manages
Protocol, XSP. The goal of XSP is to provide a dynamic allocation of network resources
general and extensible protocol to manage the including, e.g. session driven creation of LSPs
interaction between applications and network- through MPLS networks, VLANs transported
based services, and among the devices that over Ethernet, SONET, etc., or paths
provide those services. A session, in this constructed with explicit rules being inserted
model, is generically “a period of a particular in Open-Flow [9] enabled switches.
activity.” A survey of existing technologies for Lastly, an assertion that XSP enables many of
managing data movement over cur-rent and the capabilities that are emerging as desirable
emerging network infrastructures shows that for future Internet architectures. Initiating a
a unified or generic solution for connection to a session entity, and abstracting
interacting with network services has not a direct transport layer connection away from
emerged. The challenge increases when we applications, makes it straightforward to
consider the heterogeneity of network connect two session endpoints based on an
architectures, transport layer services and “identifier”, which is distinct from a network
“location.” This has clear benefits, not the application designs. It goes without saying
least of which is mobility. The potential to that the TCP/IP, or “Internet” model [11], is
exchange protocol control information with an the dominant description framework for
intermediate point as part of a session computer network protocols. Given that
connection to an endpoint, changes the protocols are not rigidly designated into strict
security model as well. We have developed a upper layers within this model, what was
framework that allows a host to authenticate with originally defined as session layer functionality
an X.509 certificate and effectively install firewall is often explicitly implemented within
rules that allow particular transport layer
applications themselves. In fact, it has been
connections to flow through for the life of the
observed that “the session functions are
session.
actually common modules for building
mechanisms used by applications that should
II. Background of Study
be considered, in essence, libraries for the
application layer” [5]. To complicate things,
Historically, the role, architecture, and
the OSI session layer defines functionality that
necessity of the session layer have been
corresponds to features implemented within
questioned. The upper layers of the OSI
the transport layer in the TCP/IP model, e.g.
reference model [1] were conceived in the late
port numbering and the associated
1970s in an attempt to quickly standardize a
management of connections between services
reasonable working model for emerging
on well-known ports. This conflating of
protocol designs [3]. This process was mired
functionality has left designers of emerging
with disagreement and pitted the established
networks and protocols in a difficult position,
telecom service providers against the fledgling
one in which exploring any significant
computer industry, leading to a murky
functional change within the TCP/IP model
collection of functionality defining the Session,
has serious deployment consequences.
Presentation, and Application layers. What
We are also not alone in realizing that the
arose from this debate were session layer
current Internet model has a number of
capabilities that dealt with various dialog
challenges to overcome. As devices become
control and synchronization primitives, which
more mobile, intermittent, and increasingly
were strongly opposed by those in the
heterogeneous, the well-established protocols
ARPANET camp. These primitives served to
within the transport layer in particular have
establish a specific set of protocol de-sign
created a number of roadblocks in supporting
patterns in various telecommunication arenas
emerging network architectures. Projects such
but this strict layering of functionality was
as Mobility First [5] are developing collections
charged with complicating, the development of
of services for supporting the explosion of
future applications within emerging computer
mobile devices on the Internet, which taken
networks. In the end, a consensus emerged
together hope to address new modes of
that acknowledged that even if these functions
routing, naming, and in-network storage in
were not in the best place; they were close
future real-world and experimental
enough for practical, engineering purposes
architectures. Others have proposed breaking
and could be sorted out as the upper layers
up the trans-port layer to better manage
became better understood. This debate, of
addressing, congestion, and flow control
course, was never fully resolved. In many
through the introduction of additional Flow
ways, this lack of resolution has led to some of
Regulation and Endpoint layers [18].
the challenges facing the Internet today, while
Although these motivations are all sound, we
upper layer protocol considerations as
believe that significant architectural changes
originally defined in the OSI model have
can be best realized through the
received little attention in most network
establishment of a dedicated session layer that
encompasses control and data plane have adapted SIP to provide “name-routing” in
management functionality without seriously an end-middle-end middlebox architecture. A
disrupting the operation of existing transport drawback of SIP from the perspective of our
layer features. Our work with XSP addresses work is that it only performs signalling out-of-
both the control and addressing of transport band and does not provide an integral data
layer connections while providing a framework movement service, limiting its applicability as
for incremental deployment with existing a general purpose framework for end-to-end
implementations. services. On the other end of the spectrum,
TESLA [10] provides an end-to-end session
The session layer itself has been experiencing architecture for the management of data flows,
renewed interest in recent years. Particularly routing, and migration without considering in-
in the realm of mo-bile and delay-tolerant dependent configuration and management of
networks, the session layer can en-capsulate a network de-vices and path services.
number of capabilities for managing transport
re-binding, device naming, and connection In addition to SIP, a number of other protocols
recovery and check pointing [15, 11]. As relate directly to XSP. We have investigated
initiatives such as FIND [7] explore the future integrating relevant features of SCTP [12]
direction of the Internet, many consider these such as multipathing and the bundling of
features to be desirable. Indeed, as networks SCTP associations as potential elements for a
be-come increasingly dynamic and network session-based signalling and data movement
topologies, connectivity models, and usage service. The Delay Tolerant Networking
patterns become more varied, they may be Research Group (DTNRG) [16] and its
essential. Traditional end-to-end arguments associated Bundle Protocol [22] attempts to
are also being re-evaluated as these solve the problem of message delivery and
architectural changes drive new modes of routing in challenging network environments,
operation [13]. I strongly agree that XSP is in including very large delay transmission and
a position to address not only the needs of the frequently disconnected network paths.
current Internet, but those of evolving future Recently, a session layer for DTN [19] has
internet architectures. been proposed that will allow receiver-driven
applications to manage relationships between
individual “bundles”. Mapping multiple
III. Related Work transport streams as in SCTP, and the
Although there has been relatively little ordering and timing of messages within a
published work in protocol development at stream as in DTN, are directly addressed by
layer 5, there have been numerous middlebox, XSP in a single framework.
overlay, and control plane protocols pro-posed There have been a number of proposed
over the years that share common aspects middlebox communication frameworks whose
with XSP. We now briefly survey related work functionality may be generalized with XSP. We
that has influenced our own design criteria share a common motivation with the inter-
and choices. middlebox architecture MIDCOM [15], de-
Perhaps the most widely known protocol signed to embed application intelligence into a
providing session layer functionality is the network of MIDCOM agents. Using a standard
Session Initiation Protocol (SIP) [7]. Its inter-agent protocol, MIDCOM focused on
primary use is in enabling state and signalling firewall and NAT services as well as the
for multimedia communication sessions, management of bundled session applications
which may utilize a number of underlying data like VoIP. Unfortunately, MIDCOM never saw
stream protocols such as RTP and RTSP. Even deployment in the real world and has since
so, some approaches such as NUTTS [20] developed in other directions.
More recently, ForCES [20] proposes to pro- when appropriate. In general, the
vide a framework for logically separating management a number of separate transport-
control and data planes within network specific features allows XSP to take advantage
processor devices. It primarily focuses on of an end-to-end path that requires the
integrated systems such routers and other configuration and traversal of path segments
net-work appliances while defining the that have unique characteristics. Thus, a
protocol for communication between distinct primary goal of XSP is to provide a core set of
control and forwarding elements. The scope of functionality and associated signalling
ForCES is tied to the interaction of closely required for network services and applications
coupled network elements whereas XSP aims to exchange and negotiate capabilities in a
to provide a more general approach to common and easily extensible framework.
signalling across applications and devices
from an end-to-end perspective. We envision The XSP session layer is designed as a
that XSP may interface with a ForCES control collection of modular session layer service
element for managing that particular class of handlers, or XSP-SH, that are accessed
network device. through a common API. Providing a standard
The Next Steps in Signalling (NSIS) [8] interface to the network, each XSP-SH uses
working group proposes a two-layer IP the underlying XSP protocol to communicate
signalling standard focusing on QoS signalling between session-enabled endpoints. Any and
and a reuse of existing reservation proto-cols all session functionality de-fined by XSP
such as RSVP. Similarly to FoRCES, NSIS is resides above the transport layer, keeping the
targeted at a specific set of use cases involving existing lower layers of the Internet model
network device con-figuration that we believe intact. Our XSP network architecture is
fall under our XSP signalling model. illustrated in Figure 1, with the XSP-SH layer
In addition, our approach utilizes some indicated by dotted boxes.
guidelines from BEEP [11], a framework for
developing network application protocols. Each XSP-SH provides a framework for
implementing a specific instance of that
IV. The XSP Session Layer service for the application. For example, the
Security XSP-SH makes available a number of
different authentication methods that can be
requested, including anonymous, username or
pass-word, X.509/SSL, SSH, and so on. The
XSP-SH layer is implemented as a set of
modular libraries that can be dynamically
loaded when requested by the application. Ad-
additional modules can be added by simply
implementing another handler within the
desired XSP-SH framework. The use of various
control and data channels is supported with
Figure. 1: XSP stack architecture the Protocol Channel XSP-SH, and
Naming/Addressing allows for the integration
A key insight in this work is that an of external endpoint location and identification
articulated, session-based network path can systems.
provide a number of benefits for managing One of the challenges for the XSP-SH
connections, in terms of control and data abstraction is defining the core set of features
messaging, as well as improving the that the session layer should provide. While
performance of the configured data channel the current XSP-SH layer enables applications
to use what we consider a common set of
built-in features (i.e. the current state of the
art), the true advantage is realized with the VI. Use Model
extensibility of the frame-work for supporting
additional capabilities as future network.
In conjunction with the development of XSP, I
have applied session layer architecture in
V. Application Support
addressing specific issues within today’s
The core XSP library is known as libxsp. Internet. I now focus on two use models that
Building an XSP-enabled application involves integrate XSP in order to improve wide-area
linking against libxsp to access the main network performance and provide a standard
protocol functionality, XSP-SH frame-work, interface for dynamic network configuration.
and configurable connection support for Primitive Description
establishing new sessions. An Application Establish a new XSP session. Session NE hops
SESS OPEN may be specified in option blocks.
XSP-SH provides hooks for supporting SESS
CLOSE Close an existing XSP session.
application messaging via external modules, Acknowledge a received XSP message. May
as described above. These application-defined SESS ACK contain additional information within an option block.
Negatively acknowledge a received XSP message. May
handlers implement the desired message SESS NACK contain an error indication within an option block.
SESS DATA Open a new data connection bound to the current
format and serialization/deserializaition OPEN session.
SESS DATA Close a data connection bound to the current
methods needed to process the message before CLOSE session.
being encoded/decoded by the XSP protocol SESS DATA
CHK Checkpoint or synchronize data connection.
implementation. This approach allows XSP to SESS APP Send application-specific data within registered
DATA option blocks.
communicate application-specific information SESS AUTH
TYPE Send and negotiate authentication type.
in a general manner while simultaneously SESS NET Configure a network path defined as a common set
maintaining session state between a number PATH of rules.

of associated NEs.
Table 2: A subset of XSP primitives
The current XSP implementation includes a
Sockets API-compatible client library, libxsp
Achieving reliable, high-speed data transfer
client, that is being retooled to expand feature
performance remains a “holy grail” for many in
support. This provides familiar semantics
the research and education (R&E) and e-
such as open, close, connect, send, receive
Science communities, and it is increasingly
and extends these with session-specific calls
important for the commercial sector as well.
that interact with the XSP-SH layer. Thus, an
While available link and backbone capacity
application may establish a session for a
have rapidly increased, the achievable
reliable, stream-oriented connection, as would
throughput for typical end-to-end applications
be provided by TCP, while being able to
has failed to increase commensurately. In
configure a desired authorization scheme,
many cases, application throughput may be
dynamic network path, separate data
significantly less than what is theoretically
channels, etc., all from a common interface.
achievable unless a considerable amount of
effort is spent on host, application, and
The XSP implementation also provides a
network “tuning” by users and network
transparent wrapper, known as the Shim
administrators alike. The growing WAN
Library indicated in Figure 1. Using library
acceleration industry underscores this need.
interposition (e.g. via the Linux LD PRELOAD
Our earlier work with Phoebus [33, 34] is a
mechanism), the wrapper allows existing
direct response to this performance gap,
applications to take advantage of XSP without
particularly when bulk data movement is
requiring any source code modifications.
concerned. Phoebus is a middle-ware system
that applies our XSP session layer, along with
associated forwarding infrastructure, for particular window of activity, which is exactly
improving throughput in today’s networks. what our earlier definition of a session allows
Phoebus is a descendant of the Logistical via XSP. The BAG operation is asynchronous
Session Layer (LSL) [10,11], which used a in that the producer is only notified of a
similar protocol and approach. Using XSP, transfer completion if requested or required by
Phoebus is able to explicitly mitigate the the implementation, and typically via an out-
heterogeneity in network environments by of-band message. An analogy can be drawn
breaking the end-to-end connection into a between BAG and that of shipping packages
series of connections, each spanning a via UPS or FedEx. The sender is not, generally,
different network segment. In this model, continuously involved with the delivery of their
Phoebus Gateways (PGs) located at strategic items from one location to another. Instead,
locations in the network take responsibility for UPS is notified that some number of packages
forwarding users’ data to the next PG in the are available at a particular address for
path, or to the destination host. The Phoebus pickup, the sender makes them available at
network “inlay” of intelligent gateways allows their front door, and UPS “gets” the packages
data transfers to be adapted at application run and delivers them to the desired destination. A
time, based on available network resources sender may even request delivery confirmation
and conditions. which can be received or checked “out-of-
band” via a web site.
In order to adapt between protocols along What BAG requires is the ability to decouple
different net-work segments, Phoebus uses the the sender (really the host operating system)
Protocol Channel XSP-SH to implement a from the task of pushing the actual data
number of transfer backends. These backends through the network, freeing up the system to
can then be used interchangeably via the perform other tasks, just as UPS frees a
shared XSP API while the underlying XSP shipper of packages to go about their day.
framework handles any differences in protocol Fortunately, the rapidly evolving area of
semantics. The existing Phoebus Remote Direct Memory Access (RDMA)
implementation has developed and technologies has provided exactly this
experimented with a number of protocol capability.
backends, including TCP, UDP, and MX [21],
as well as userspace protocol implementationsThe BAG approach draws inspiration from
such as UDT [14]. One alternative is todata center environments where switched-
decouple the data movement over the network fabric interconnects like InfiniBand and
from the involvement of the operating system similar RDMA protocols have played a
itself. In this model, sending a resource, significant role in enabling massive
whether it be a set of files or data already parallelization with improved throughput and
within the page cache, involves let-ting the OS
reduced latency and overhead. Supporting
simply stage the data in memory on behalf of zero-copy networking, RDMA operates on the
the requesting application while allowing theprinciple of transferring data directly from the
remote host to asynchronously “get” the memory of one system to another, across a
prepared memory regions via some transport network, while bypassing the operating system
mechanism. We call this particular type of and eliminating the need to copy data between
transfer scenario Bulk Asynchronous GET, or user and kernel memory space. These direct
BAG. memory operations are supported by enabling
net-work adapters to register, or “pin”,
The BAG approach entails having a memory and directly access these explicitly
producer make some resources available for a allocated regions without involvement or
remote consumer to ac-cess, during some context switching from the host operating
system. necessary local and remote addresses, keys,
Recently, enhancements to Ethernet for and size of each mem-ory region to transfer.
“data center bridging” have led to RDMA
implementations that run directly over Figure 3 shows a system-level view of XSP
existing layer-2 network infrastucture, using provid-ing the necessary signaling to maintain
RDMA-enabled network adapters called rNICs. a BAG transfer. After the XSP session
By allowing the network adapter to establishes the RDMA context, registers local
encapsulate memory-resident application data and remote buffers, and exchanges point-ers,
within layer-2 frames directly, the overhead of the rNICs proceed to transfer data within the
higher level protocols can be virtually desig-nated memory regions without further
eliminated. A number of RDMA over Ethernet involvement from the OS. What is missing
(RoE) im-plementations are under from this picture is the service that “stages”
development and a standard for high- requested data in memory to be transferred.
performance Ethernet rNICs has been
proposed and implemented within currently VII. SLaBS with XSP-BAG
available hardware [3, 20].
The first implementation of the BAG approach
extends SLaBS with the ability to use RDMA
over Ethernet to more efficiently transfer slabs
across dedicated network paths. Here, the
memory regions to GET are the slab SP-DUs
being buffered at the SLaBS gateway and the
main challenge involves extending the
Figure 3: System-level view of RDMA transfers with
threaded buffer model within SLaBS to
XSP-driven Bulk Asynchronous GET (XSP-BAG) support efficient BAG transfers over high-
latency WAN paths.
Using XSP, I analysed a conceptual model of
a BAG service that uses an RDMA transport
and have begun implementing the necessary
components within the XSP session layer. This
has involved two main tasks: (i) creating an
RoE Protocol Channel XSP-SH, and (ii) adding
XSP option types that allows the appli-cation
to exchange the necessary metadata to Figure 4: SLaBS “triple buffering” for XSP-BAG
perform the remote GET operations and signal
As network latency increases, it is well
transfer comple-tion events. The RDMA
understood that pipelining the transmission of
protocol handler in XSP-SH uses the
network buffers is required in order to
OpenFabrics [12] rdmacm and Infiniband ib-
continually keep data “in-flight” within the
verbs libraries to establish the RDMA
net-work. TCP solves this with a sliding
transport context and initiate the supported
window protocol clocked to the round-trip
RDMA operations. The em-ployed Infiniband
time (RTT) of the path, the effects of which
“RDMA READ” operation is equiva-lent to the
become exaggerated over so-called “long fat
GET described in Bulk Asynchronous GET
networks” leading to considerable performance
and requires the exchange of memory region
issues. In contrast, SLaBS maintains an open
pointers to move data from one RDMA-
loop model over the dedicated core network
connected host to another. The XSP option
paths which allows us to determine ahead of
blocks defined for BAG transfers (option type
time what resources are necessary and to pace
XSP OPT BAG) encode and exchange the
slab transfers based on buffer and throughput included 8GB of high-speed DDR2 RAM. The
capabilities at various points in the network. gateways systems were outfitted with two
This amounts to ensuring that the buffering Mellanox rNICs in order to evaluate SLaBS
implementation has at least one bandwidth- per-formance with native, or “hard”, RDMA
delay product1 (BDP) sized buffer in transit at over Ethernet.
any given time. However, in the BAG model Figure 5 shows that at 10Gb/s, the SLaBS
with RDMA, there is an inherent trade-off gateway systems are not able to successfully
between the number of registered memory form slab SPDUs and simultaneously burst
regions and total buffer size required to buffered slabs over either TCP or UDP data
saturate the given network path. channels. Increasing the number of additional
incoming streams does not significantly affect
Our current SLaBS buffer implementation, the buffering or backend performance. With
illustrated in Figure 4, uses an adjustable size the XSP-BAG extensions and the RDMA data
ring buffer with configurable memory region channel, the slab bursting performance nearly
partitions within the overall buffer. To simplify matches that of only writing SPDUs into the
the amount of memory region metadata ex- slab buffer from the edge connections. Indeed,
change required with XSP, we employ a simple the RDMA data channel transmits at the
“triple buffering” scheme where three memory maximum bandwidth achievable by the rNIC,
regions are ex-changed between SLaBS approximately 9.71Gb/s. As the WAN latency
gateways in a round-robin fashion to keep the is increased, direct TCP performance suffers
network saturated. While incoming SP-DUs whereas with SLaBS, and the RDMA data
are written to one region, the second region is channel enabled, observable transfer
a “ready-to-send” slab and its associated performance remains consistent beyond
metadata has al-ready been sent to the remote 100ms, improving upon the direct TCP
side within an XSP slab option block. The transfer by up to 18% in the highest latency
remote side posts the GET operations as they case.
are received over the XSP control session while 10

9
a third region is continuously being retrieved.
8

6
VIII. Performance Evaluation
Gb/s

5
This section presents on initial performance
4
results as evaluated using the XSP-BAG buffer only
3
additions to the SLaBS gateway system. All RDMA send
2 TCP send
results were collected from a testbed UDP send
1
environment consisting of 7 nodes connected 0
with 10Gb/s Myri-com Ethernet NICs, each 1 2
No. Of Connections
4 8

node having at least two 10Gb/s interfaces. Figure 5: SLaBS data channel performance
The testbed forms a linear network topology
with client and server nodes at the edges, two
SLaBS gateways in the middle, and 3 delay
nodes segmenting the network into
representative LAN and WAN segments. The
edge host and netem nodes were Sun X2200
servers with quad-core AMD Opteron CPUs
and 4GB of RAM, while the gateway systems
contained AMD Phenom II X4 processors and
 date, we have implemented handlers for
OSCARS, Terapaths, and OpenFlow and have
begun implementations for NETCONF and
end-host network configuration for Linux-
based systems.

Figure 9: An xspNetPath structure contains a list of

“rules” to be configured by the indicated netPath
XSP-SH modules

In order to provide a common interface for

each handler, the netPath framework
abstracts a set of configuration parameters, or
“network rules”, that are needed to configure
the underlying network device. Each netPath
XSP-SH implementation uses this common
abstraction to install a given network rule as
determined by the specified XSP-SH handler
type. By realizing that a large majority of
network configuration tasks involves only a
few core set of operations, we have been able
to create rules that can be expressed with a
relatively short list of parameters. In this we
share a common theme with Open-Flow and
Figure 8: SLaBS CPU Overhead their n-tuple for defining all configurable flows
in an OpenFLow capable switch. Configuring
SlaBS is able to achieve full WAN network
dynamic network paths in particular is
utilization well beyond 100ms, covering a large
typically a process of bring-ing up the
number of typical WAN path latencies while
appropriate interfaces, installing a number of
requiring a memory footprint achievable in
forwarding rules, and applying a set of
most network service platforms.
properties such as QoS bits and VLAN tags, or
capacity and duration con-traints in the case
IX. XSP netPath Model of DNE reservations.
Since the early work with Phoebus and its The netPath interface exported via the XSP API
ability to act as an application “on-ramp” for presents an xspNetPath structure to the
DNEs, the extent of the XSP framework allows application which can specify a set of dynamic
for more general network configuration. The path actions such as CRE-ATE, MODIFY,
netPath XSP-SH now enables the extensible DELETE, QUERY, etc. This structure can be
and interchangeable use of an increasingly manipulated to contain a number of
growing subset of the above technologies. To xspNetRule entries that, taken together,
defines an end-to-end path, or it may simply exportable view of active paths and associated
contain a single rule to effect some particu-lar network device configuration within a given
configuration on a specific device. Figure 9 network domain. Clients interfacing with the
illustrates this structure. UNIS service can query path information to
The xspNetPath structures are encoded within learn the state of the network and actively
XSP option blocks and sent along the active modify device configurations using XSP
session as SESS NET PATH messages. An XSP netPath. In a similar fashion, XSP NEs may
NE configured with the netPath XSP-SH update UNIS with the current status of the
indicated within the xspNetRule en-tries load device configuration by updating rule
the appropriate handler and applies the annotations in the topology description.
specified configuration. An XSP EID within the
xspNetRule en-tries allow the netPath Using UNIS and XSP netPath, we are in the
handlers to identify and locate the particular process of creating and evaluating the
network device or service to configure. The effectiveness of network environments similar
underlying handler interacts with the active to the one shown in Figure 11. Within each
session to pro-vide acknowledgements if the network, XSP NEs with netPath handlers
operation completed successfully, or manage the configuration of a number of
descriptive NACKs if it was unable to apply network devices within a particular domain.
some or all of the device configuration. These running XSP instances may be part of a
deployed gateway such as Phoebus or are
The Unis Schema: A Conceptual View other-wise made available as standalone XSP
services or host agents depending on the end-
The UNIS schema builds upon the same base site deployment. By providing a standard
elements as defined in the NM-WG [6] interface and session negotiation between
topology schema used by perfSONAR and netPath handlers, XSP can automatically
allows for interoperability between sys-tems. configure dynamic network paths on behalf of
These base elements allow networks to be the requesting application based on topology
described in terms of domains, nodes, ports, information obtained from UNIS, bringing the
links, networks, paths, and services in a “virtual circuit” all the way to the end-host if
flexible and extensible manner. We have desired. Finally, one of the additional features
recently extended the UNIS schema to allow UNIS provides is that of service lookup and
for annotations to these base elements so as name resolution. If not resolveable via the
to include network configuration, or “rule”, local XSP NE configuration, the EIDs specified
information within the network topology within each xspNetRule are located with
description itself. An example of such a queries to UNIS, which maintains registered
topology fragment is show in Figure 10. In service information along with network
this model, a net-work path in UNIS can be topology.
represented as a list of rule references, which
are annotations to node, port, and service
elements within the topology description.

The similarity to the XSP netPath model is not

by accident. In fact, resolving a UNIS path of
rule references is intended to represent the
same network configuration information in the
equivalent xspNetPath structure. This has a
number of benefits, not the least of which is Figure 11: Conceptual view of the netPath XSP-SH
the ability to maintain a consistent and being used to provide a common interface for
dynamic network configuration, in this example Cisco locator/id separation protocol.
creating a “virtual circuit” between two remote http://lisp4.cisco. com/.
domains.
[1] Connectx-2 EN with RDMA over
Ethernet (RoCE).
X. Conclusion http://www.mellanox.com/related-
docs/prod_ software/ConnectX-
This paper presents the XSP session layer and 2_RDMA_RoCE.pdf.
protocol implementation as an extensible Juniper Junos SDK.
framework for managing the interaction http://www.juniper.net/us/en/
between applications and network-based products-services/nos/junos/junos-sdk/.
services. Given the scope of our architecture, I Mobilityfirst future internet architecture
have focused on two use models in particular project. http://
and describe how XSP is being applied to mobilityfirst.winlab.rutgers.edu/.
improve performance in modern networks and Network Measurement Working Group.
dynamically configure dedicated network http://nmwg. internet2.edu/.
paths on which our performance-enhancing NSF NeTS: Future Internet Design Initiative.
middleware services depend. An illustration of http://www. nets-find.net/.
Bulk Asynchronous GET approach as a model NSIS: Next steps in signaling.
for how XSP can merge technologies and http://datatracker.
ietf.org/wg/nsis/charter/.
services from opposite ends of the networking
spectrum, from data centers to wide-area OpenFlow: http://www.openflowswitch.org/
documents/openflow-wp-latest.pdf.
networks, into a single, common interface for
applications and users. As the Internet Unified Network Information Service.
https://spaces.
continues to evolve, I believe XSP is positioned
internet2.edu/download/attachments/6
as a general and extensible platform for 881319/ UNIS_white_paper.pdf.
exploring future internet architectures. [2] Requirements for internet hosts -
communication layers, 1989.
XI. Acknowledgement
I would like to appreciate those who helped in [3] T. Benjegerdes. Infiniband and openfabrics
numerous ways to make this work a success. I at sc06. In Proceedings of the 2006
would like to acknowledge the guidance of my ACM/IEEE conference on
lecturer Mr. Prasad C.N for spurring me up to Supercomputing, SC ’06, New York, NY,
greater heights. My sincere thanks to all the USA, 2006. ACM.
faculty of Computer Science Department, St.
Joseph’s College (Autonomous) Bangalore- [4] M. S. Blumenthal and D. D. Clark.
India for their words of encouragement. Most Rethinking the design of the internet: the
importantly, I thank my Lord Jesus Christ for end-to-end arguments vs. the brave new
his countless blessings upon my life and world. ACM Trans. Internet Technol.,
family. 1(1):70–109, 2001.

[14] IOSR Journal of Computer Engineering

(IOSR-JCE) e-ISSN: 2278-0661, p- ISSN:
XII. References 2278-8727Volume 16, Issue 4, Ver. I (Jul-Aug.
Cisco Application Extension Platform. 2014), PP 01-05 (Neema Merlin Rodrigues,
http://www.cisco. Anasuya K Lingappa)
com/en/US/products/ps9701/.
[15] Donald L. Evans: Computer Security
Division Information Technology Laboratory
National Institute of Standards and
Technology Gaithersburg, MD 20899-8930
November 2002, U.S. Department of
Commerce.

[16]. http://ipv6.com/articles/general/IPv6-
The-Future-of-the-Internet.htm

[17].http://www.nojitter.com/post/24014554
6/ipv6-and-the-future-internet-problems-
created

[18].http://www.computer.org/csdl/mags/ic/
2012/06/mic2012060011.html

[19].http://www.hit.bme.hu/~farkask/publica
tions/ipv6_english.pdf

[20].http://nes.aueb.gr/publications/FIAbook
2011.pdf

[21]. http://en.wikipedia.org/wiki/Middlebox

[22]. Manjunath Ramachandra, Pandit

Pattabhirama: Analysis of the High-Speed
Network Performance through a Prediction
Feedback Based Model, Philips Innovation
Campus, India

[23]. Bhavya Daya: Network Security: History,

Importance, and Future, University of Florida
Department of Electrical and Computer
Engineering.