This talk is motivated by the belief that the next generation of advanced networked applications (i.e., Net+, Cloud based services) will require integration and co-scheduling of Network, Middleware, and Application level services. These networked applications will be user focused and driven by domain specific requirements. A new class of "intelligent network services" must emerge in order to feed the co-scheduling algorithms which will be searching for real-time and scheduled solutions based on client requests. In this talk we present results from the ARCHSTONE (Advanced Resource Computation for Hybrid Service and TOpology NEtworks) project which has added functionality to the OSCARSv0.6 system to provide these types of "intelligent network services". This includes a framework for "modular composable network services" and an advanced multi-dimensional resource computation engine that allows clients to ask the network "what is possible?" questions as part a larger workflow and co-scheduling activity. Use of these network services by the Virtual Network On Demand (VNOD) co-scheduling workflow is described. We also describe our plans to utilize OpenFlow to expand on the set of available network services to develop even more advanced application services based on this paradigm.

2. • USC/ISI • BNL
• Tom Lehman • Dimitrios Katramatos
• Xi Yang • Sushant Sharma
• ESnet • Dantong Yu
• Chin Guok
• Eric Pouyoul
• Inder Monga
• Vangelis Chaniotakis
• Bharath Ramaprasad (UMass)
• UNM
• Nasir Ghani
• Feng Gu
• Kaile Liang

4. • Network "Service Plane" formalization
• Composable Network Service architecture
• ARCHSTONE Network Service Interface as client entry point
• Extensions to Topology and Provisioning Schemas to enable:
• multi-layer topologies
• multi-point topologies
• requests in the form of a "service-topology"
• vendor specific features
• technology specific features
• node level constraints
• MX-TCE (Multi-Dimensional Topology Computation Engine)
• Computation Process and Algorithms
• Enable a New class of Network Services referred to as "Intelligent
Network Services"
• clients can ask the network "what is possible?" questions
• can ask for "topologies" instead of just point-to-point circuits

5. • Advanced Network Service Interface
• "Request Topology" and "Service Topology" concepts
• Common Network Resource Description schema
• Network Service Plane access point
• Multi-Dimensional Topology Computation Element (MX-TCE)
• High Performance computation with flexible application of constraints
• Use OSCARSv6 as base infrastructure and development environment
request
Network Network
Service Provider
Requester Agent
OSCARSv6
reply
MX-TCE
Network
Resource
Description

6. Network Services
Interface
Network Service Plane
Composite Service (S1 = S2 + S3)
Composite Service Composite Service
(S2 = AS1 + AS2) (S3 = AS3 + AS4)
Atomic Atomic Atomic Atomic
Service Service Service Service
(AS1) (AS2) (AS3) (AS4)
Multi-Layer Network Data Plane

7. Topology Service to determine Security Service (e.g.
resources and orientation encryption) to ensure data
integrity
Resource Computation Service* Store and Forward Service to
to determine possible resources enable caching capability in the
based on multi-dimensional network
constraints (*MX-TCE)
Measurement Service to
Connection Service to specify
enable collection of usage data
data plane connectivity
and performance stats
Monitoring Service to ensure
Protection Service to enable
proper support using SOPs for
resiliency through redundancy
production service
Restoration Service to facilitate
recovery

8. • Extensions to OSCARS v0.6
• Added features for:
• multi-layer topologies
• multi-point topologies
• requests in the form of a
"service-topology"
• vendor specific features
• technology specific features
• node level constraints
• Result is a schema
"Superset" to what
OSCARSv0.6 now uses
• schema with ARCHSTONE
extensions will be backward
compatible with current
OSCARS operations
• Uses perfSONAR Topology
and Lookup Services

9. • MX-TCE role in OSCARS
• perform basic path computation for current OSCARS service
• standalone Topology Computation element to: answer "what is Client
possible?" questions for clients to subsequently make request for Application
OSCARS services
• Advanced multi-layer and multi-point computations
What topologies are
available next week for
3 hour duration?
Current OSCARS Service: Here's Two
"Please try and reserve a 5
Gbps VLAN circuit between
A and B at 15:00 on January
16, 2012 for 3 hour
duration"
MX-TCE
Client
Application
can perform basic
path computations as
needed to respond to
current OSCARS
point-to-point VLAN
service

10. java web service, C++ multi-threaded core

11. • Unified API/NSI support for P2P, Multi-Point, Multi-Layer,
schedule and co-scheduling requests under extended NML
schema
• Implemented OSCARS PCE API to become swappable
OSCARS module
• support existing OSCARS PCE capability as a single TcePCE
• support co-scheduling via optionalConstraint extension
• Multiple path and topology computation workflows
• kicked off based on request types: P2P, MP, MLN/MRN, coSheduling
etc. and combinations
• support concurrent requests through multi-threading
• Modularized differentiated algorithm execution driven by
workflows
• Transform computation results into
• provisioning friendly path object depending on path control scenarios
• NSI and OSCARS compliant reply messages

13. • ARCHSTONE Extensions • Layer Decisions
• Multi-Layer Topology Representations • driven by resource constraints or
• Multi-Layer Topology Computations client requests for specific
• Multi-Layer Provisioning performance characteristics (i.e.
low latency, low jitter, etc)

14. • Prototype Deployment on Production Networks
• ESnet and Internet2
• Real-time reservations being processed to provide answers to "what is
possible?" questions that client can then use to make requests on the
operational networks
• VNOD project will discuss a specific use case for this
Client
Application
coScheduleRequest:
start time: Wed, 08 Feb 2012 05:00:00 GMT
end time: Wed, 08 Feb 2012 07:00:00 GMT
min bandwidth: 1 Gbps
max number of path options: 3
format for reply: bandwidth availability graph
OSCARS MX-TCE
OSCARS
real-time reservations feed
from production networks

15. • archstone.east.isi.edu
• Architecture and Design Documents
• MX-TCE Software
• Extensions to OSCARS Topology and Request
Schemas
• Example topology descriptions, service requests,
service topologies (responses)
• ANI Testbed configuration and use
• OSCARSv0.6 project
• code.google.com/p/oscars-idc/
• OSCARS ARCHSTONE Branch
• oscars.es.net/repos/oscars/branches/archstone/

16. • Virtual Network On Demand (VNOD) is a project funded by DOE ASCR
• Objectives:
• To provide on-demand, end-to-end virtual network topologies dedicated
to servicing communities of users at multiple end-sites
• To facilitate the creation and management of such virtual network
domains
- VNOD GUI based front-end
• To provide a platform for applying various optimization schemes with
diverse objectives
- Successfully schedule multiple, fixed and flexible, end-to-end data
transfer requests between multiple end sites and hosts
• Currently working on developing technologies to address the
integration and co-scheduling across Network and Middleware level
resources
• This includes co-scheduling algorithms, protocols, and workflows which
can operate in this "distributed heterogeneous multi-resource
environment"
• Leveraging TeraPaths and ESCPS for end-host and site
communications and configurations
• Future work will include integration with application specific
workflows and systems
• Utilizing ARCHSTONE Intelligent Network Services as part of co-
scheduling workflows

17. End Site End Site
End Site
ESDC Transit WAN
IDC
Transit WAN
Transit WAN
End Site
End Site

18. Topology Community
Topology distributed auxiliary
Community Service Membership
Service
Membership services service
service
Service Service
Discovery Monitoring Discovery Monitoring
Service Service
ViNet
request Resource Scheduler (RS) Resource Scheduler (RS)
(application (selects and schedules (selects and schedules
requirement resources) resources)
profile)
VNOD VNOD
remote RSs
remote RSs ViNet Controller (VNDC) ViNet Controller (VNDC)
(creates and manages (creates and manages
remote VNDCs ViNets) ViNets)
remote VNDCs
virtual networking layer
virtual end-to-end path layer
remote ESCPS remote ESCPS
negotiation ESCPS ESCPS Negotiation
OSCARS OSCARS
with ARCHSTONE with ARCHSTONE
Transit WANs
End-Site LAN End-Site LAN

20. • VNOD workflow:
• User requests a virtual domain setup via the front-end
- Request can come from an application via the API
- End-system resource availability (e.g., storage system bandwidth)
can also be submitted for co-scheduling
• The VNOD back-end:
- Collects bandwidth availability information from domains involved in
virtual path establishment
• Interfaces with ARCHSTONE for WAN domains and TeraPaths/
ESCPS for end-sites
- Runs scheduling algorithm(s)
- Makes appropriate reservation requests based on algorithm output
by engaging ARCHSTONE and TeraPaths/ESCPS

21. +
End Site
A
+
Transit WAN W1
Transit WAN W2
or
+
End Site
or B
+
+

22. (a) (b)
(c) (d)

23. Available Bandwidth (Gb/s)
Step 1
10
Step 3
8
Step 0 Request #2
6
Step 2
4 Request #1
Request #3
2
Request #0
0 1 2 3 4 5 6 7 Time (secs)

24. • Implementation in progress
• Increasingly difficult scheduling problems:
• Single request/single path (TeraPaths/StorNet)
• Multiple requests/single path/single WAN domain
• Multiple requests/multiple paths/single WAN domain
• Multiple requests/multiple paths/multiple WAN domains
• Co-design with ARCHSTONE to attack
scheduling complexities
• Hierarchical scheduling (end-sites/WAN)
• Tighter integration and interoperation

25. • The architecture adopted by ARCHSTONE, OSCARS, VNOD:
• Centralized at the Intra-Domain level for resource management and service
provisioning
• Distributed at the Inter-Domain level for resource management and service
provisioning
• External topology distribution systems must limit the amount dynamic data
exported (scalability and stability issues)
• Resource identification for real-time service provision can only be done by local
domain systems
• Multi-domain service provision will require chain or tree mode protocols which
include real-time negotiation/multi-phase commit features
• "Intelligent Network Services" is the key capability that needs to be developed
next to support co-scheduling across network, middleware, application
domains – Network API needed to make service available to workflow engines
• OpenFlow/Software Defined Networking offers a set of network capabilities
which can enhance these "Intelligent Network Services"
• but the "Intelligent Network Services" and co-scheduling technologies are the
distinct and key value added feature set that we are addressing