# Presentation: 877399

## DRAGONDynamic Resource Allocation via GMPLS Optical NetworksPresented to the NASA Optical Network Technologies Workshop August 8, 2004

- Jerry Sobieski
- Mid-Atlantic Crossroads (MAX)
- Tom Lehman
- University of Southern California
- Information Sciences Institute (USC ISI)
- Bijan Jabbari
- George Mason University (GMU)
- Don Riley
- University of Maryland (UMD)

**National Science **
**Foundation**

## DRAGON Overview:

- Funded under the NSF Experimental Infrastructure Networks (EIN) program
- Four year project, began September 2003
- Purpose: Enable new capabilities for e-Science applications
- Project Features/Objectives:
- Dynamic provisioning of dedicated network resource paths – end-to-end, heterogeneous, multi-domain
- All-optical, switched metro/regional scale network
- Integrated constraint based routing for both intra-domain and inter-domain light path provisioning
- Simple, intuitive APIs to define, reserve, schedule, and instantiate complex application-specific topologies associated with distributed e-science applications
- Develop and validate architectural model for advanced light path services, and address migration path and adoption issues for wide scale deployment

## DRAGON Team Members

- Mid-Atlantic CrossRoads (MAX/UMD)
- University of Southern California Information Sciences Institute (USC/ISI)
- George Mason University (GMU)
- Movaz Networks
- MIT Haystack Observatory
- NASA Goddard Space Flight Center (GSFC)
- US Naval Observatory (Wash., DC)
- University of Maryland College Park (UMD)
- NCSA (National Center for Supercomputing Applications) ACCESS Center

## End to End GMPLS TransportWhat is missing? 

**End to End GMPLS Transport****What is missing? **

- IP/Ethernet
- campus LAN

- Integration across
- Non-GMPLS enabled
- networks

- IP/ {Ethernet, sonet, wavelength }
- Core services

- GMPLS-RSVP-TE signaling

- GMPLS-{OSPF, ISIS}-TE
- intra-domain routing

- No standardized Inter-Domain Routing Architecture, including transport layer capability set advertisements

- No Simple API

- No end-to-end
- instantiation

## The DRAGON ProjectKey Features/Objectives

- Uses all optical transport in the metro core
- Edge to edge Wavelength switching (2R OEO only for signal integrity)
- Push OEO demarc to the edge, and increasingly out towards end user
- Standardized GMPLS protocols to dynamically provision intra-domain connections
- GMPLS-OSPF-TE and GMPLS-RSVP-TE
- Develop the inter-domain protocol platform to
- Distribute Transport Layer Capability Sets (TLCS) across multiple domains
- Perform E2E path computation
- Resource authorization, scheduling, and accounting
- Develop the “Virtual LSR”
- Abstracts non-GMPLS network resources into a GMPLS “virtual LSR”.
- Simplified API
- Application Specific Topology definition and instantiation
- Resource resolution, proxy registration and signaling

## DRAGON Architecture:All Optical Core and Edge

- Optical Core

- Optical Edge

- _Optical Edge Functions provide demarc for entry into core_
- Aggregation
- Regeneration
- Optical Conditioning

- Wavelength switches functioning as optical Label Switched Routers (LSRs) in the core

- 2R OEO Transponders allow multiple device interface types:
- gige, hdtv(smpte292), vis cluster

## Technical Issues

## DRAGON Software Development Components

- Network Aware Resource Broker
- Inter-domain routing platform to distribute Transport Layer Capability Sets (TLCS)
- Dynamically monitors IGP and/or EGP for network topology changes
- Application Specific Topology Descriptions
- Ability to formally describe deterministic network resources
- Instantiate the connections at execution time
- Virtual Label Switched Routers
- Migration path for non-GMPLS capable network components and proxies for “dumb” network attached devices (e.g. HDTV cameras)
- All Optical End-to-End Routing
- Reduce complexity (and cost) of metro/regional networks
- Minimize OEO requirements for “light paths”

## Network Aware Resource Broker (NARB) Functions – IntraDomain

**Network Aware Resource Broker (NARB) Functions – IntraDomain**

- NARB

- End
- System

- End
- System

- Ingress
- LSR

- Egress
- LSR

- Edge
- Signaling
- Authorization

- ASTDL
- Scheduling
- Authentication
- Authorization
- Accounting

- IP Control Plane

- Data Plane

- Data Plane LSP

- Signaling

- • IGP Listener		 • Edge Signaling Enforcement 		 • Authentication
- • Path Computation 	 • ASTDL Induced Topology Computations 	 • Accounting
- • Scheduling 		 • Authorization (flexible policy based)
- • Edge Signaling Authentication

- AS#

## Network Aware Resource Broker (NARB) Functions - InterDomain

- InterDomain NARB must do all IntraDomain functions plus:
- EGP Listener
- Exchange of InterDomain transport layer capability sets
- InterDomain path calculation
- InterDomain AAA policy/capability/data exchange and execution

- NARB

- End
- System

- NARB

- NARB

- End
- System

- AS 1

- AS 2

- AS 3

- Transport Layer Capability Set Exchange

## Virtual Label Switched Router - VLSR

- Many networks consist of switching components that do not speak GMPLS, e.g. current ethernet switches, fiber switches, etc
- Contiguous sets of such components can be abstracted into a Virtual Label Switched Router
- A management agent (the VLSR) can be created that interacts with the DRAGON network via GMPLS protocols
- The VLSR translates GMPLS protocol events into a generic pseudo-commands for the covered switches. The pseudo- commands are tailored to each specific vendor/architecture using SNMP, TL1, CLI, or a similar protocol.
- The VLSR can abstract and present a non-trivial internal topology as a “black box” to an external peering entity.

## VLSR Abstraction

**Ethernet network**

**GMPLS network**

**LSR**

**LSR**

- OSPF-TE / RSVP-TE

- OSPF-TE / RSVP-TE

**?**

## Application Specific Topologies

- A formalized definition language to describe and instantiate complex topologies
- Application topologies consist of multiple LSPs that must be instantiated as a whole.
- Resource availability must be dependable and predictable, i.e. resources must be reserveable in advance for utilization at some later time
- By formally defining the application’s network requirements, service validation and performance verification can be performed (“wizard gap” issues)

## Application Specific Topology Description Language - ASTDL

**Application Specific Topology Description Language - ASTDL**

- Datalink:= { Type=Ethernet; bandwidth=1g;		SourceAddress=%1::vlbid;   DestinationAddress=%2; }
- Topo_vlbi_200406 := {   	Correlator:=corr1.usno.navy.mil::vlbid;         // USNO
- 	DataLink( mkiv.oso.chalmers.se, Correlator );   // OSO Sweden   	DataLink( pollux.haystack.mit.edu, Correlator );// MIT Haystack 	DataLink( ggao1.gsfc.nasa.gov, Correlator );    // NASA Goddard
- 	}
- C++ Code invocation example:
- eVLBI = new ASTDL::Topo( “Topo_vlbi_200406”);  // Get the topology definition
- Stat = eVLBI.Create();                         // Make it so!

- corr1.usno.navy.mil

- mkiv.oso.chalmers.se

- pollux.haystack.mit.edu

- ggao1.gsfc.nasa.gov

- Correlator

- GGAO telescope

- Chalmers
- telescope

- Haystack
- telescope

- Formal Specification

- Instantiation

## The AST Process

**The AST Process**

- Master

## ASTDL Driver Example

**ASTDL Driver Example**

- #include "class_Topo.h++"
- #define DRAGON_TCP_PORT 5555;
- //
- // User prime mover "ast_master" for AST miniond
- //
- using namespace std;
- using namespace ASTDL;
- int main(int argc, char *argv[])
- {
-   int stat;
-   Topo *topo;
-   topo = new Topo(argv[1]);
-   if(topo == NULL) exit(1);
-   stat = topo->Resolve();
-   if(stat != 0) exit (2);
-   stat = topo->Instantiate();
-   if(stat != 0)
-     { cout << "Error stat=" << stat << endl; exit(3);}
-   stat = topo->UserHandoff();
-   stat = topo->Release();
-   exit(0)
- }

- Read topology definition source and create the Topo object

- Resolve hostnames and other service specific data

- Establish all the connections

- All done.  Tear it down.

## DRAGON Network

## DRAGON NetworkWashington, DC Metro Area

**DRAGON Network****Washington, DC Metro Area**

- MCLN (Level3)

- DCGW (GWU)

- ARLG (Arlington, VA)

- DCNE (Qwest)

- NLR/HOPI

- ATDnet/BOSSnet

- USNO

- UMD

- GSFC

- ISI East

- ACCESS

- Haystack

- Abilene

- CLPK (College Park, MD)

## Commercial Partner:Movaz Networks

**Private sector partner for the DRAGON project proposal**
**Provide state of the art optical transport and switching technology**
**Major participant in IETF standards process**
**Software development group located in McLean Va (i.e. within MAX)**
**Demonstrated GMPLS conformance**

- MEMS-based switching fabric
- 400 x 400 wavelength switching, scalable to 1000s x 1000s
- 9.23"x7.47"x3.28" in size
- Integrated multiplexing and demultiplexing, eliminating the cost and challenge of complex fiber management

- _Movaz iWSS prototype switch installed at the University of Maryland_

## Movaz Partnership:New Technology 

- Movaz and DRAGON will be deploying early versions of new technology such as:
- Tunable wavelength transponders
- Reconfigurable OADMs
- Alien wavelength conditioning
- 40 gigabit wavelengths
- Possibly other digital encoding formats such as RZ, DPSK, etc.
- The development and deployment plans of selected technologies are part of the annual review cycle

## Initial Applications

## Very Long Baseline Interferometry (VLBI)

## Very Long Baseline Interferometry (VLBI)

## electronic-Very Long Baseline Interferometry (e-VLBI)

- What is it?
- Radio time series are captured simultaneously by several telescopes around the world (the “Very Long” part)
- These time series are correlated pairwise (the “Baseline” part) to identify events occuring within the time series (the “Interferometry”) thus allowing the scientist to calculate very accurately *where *the event occurred.
- The traditional method for moving the time series data to the correlator sites has been via tapes and jets.
- Current methods still incur generally two days to capture and move the data to the correlator – that’s too long.
- Why are <Realtime | Near RT | on-demand> resources so important to this application?

## electronic-Very Long Baseline Interferometry (e-VLBI)

- Why is this such an interesting application to demonstrate dedicated, predictable, high performance network topologies?
- The VLBI process can be used to study the earth.
- By focusing on very distant very accurately placed objects, scientists can study the changes in the telescope baselines
- This can provide very accurate information regarding tectonic plate movement, changes in the earth’s shape due to glacial rebound from the ice age, etc.
- Most notably, VLBI’s ability to detect geodetic wobbles in the earth, allow it to predict small but important perturbations in the inertial frame of reference experienced by satellites
- The Global Positioning System uses VLBI “intensives” to continually recalculate the satellite orbital positions.
- Interestingly, these geodetic wobbles can be affected by events such as major atmospheric storms such as typhoons or hurricanes.

## electronic-Very Long Baseline Interferometry (e-VLBI)

- The GPS depends on integrated weather models and VLBI runs:
- Weather forecast models are typically 5 days out
- Minus 2 days for VLBI data transfer = 3 days prediction
- NRT data transfer will improve predictions by ~40%
- Some celestial events are unpredictable and transient, and have short durations on a scale of minutes to days
- Steering the observation NearRT allows dramatically more effective use of time on instruments
- And greatly improved opportunities to acquire useful observations on unpredictable transient events
- True real-time correlation
- Current data rates are approx 1gbs/sensor
- Expect 4-8gbs/sensor stream over next 5 years
- Real time correlation, possibly using distributed general purpose clusters (Real time first demo’d in April 2004)

## electronic-Very Long Baseline Interferometry (e-VLBI)

- MIT Haystack
- NASA GSFC (GGAO)
- USNO
- Radio Telescopes reachable via Abilene
- eVLBI Experiment Configuration

## DRAGON eVLBI Experiment Configuration

## High Definition Collaboration and Visual Area Networking (HD-CVAN) 

- HD-CVAN Collaborators
- UMD VPL
- NASA GSFC (VAL and SVS)
- USC/ISI (UltraGrid Multimedia Laboratory)
- NCSA ACCESS
- Dragon dynamic resource reservation will be used to instantiate an application specific topology
- Video directly from HDTV cameras and 3D visualization clusters will be natively distributed across network
- Integration of 3D visualization remote viewing and steering into HD collaboration environments

## Uncompressed HDTV-over-IPCurrent Method

- Not truly HDTV --> color is subsampled to 8bits
- Performance is at the mercy of best-effort IP network
- UltraGrid processing introduces some latency

**SMPTE-292**
**HDTV output**
**1.485 Gbps**

**LDK-6000**

**850Mbps**
**RTP/UDP/IP**

**network**

**Astro 1602 DAC**

**PDP-502MX**

**Notes:**
Requires over-provisoned paths
At the mercy of networks vagaries

## Low latency High Definition CollaborationDRAGON Enabled

- End-to-end native SMPTE 292M transport
- Media devices are directly integrated into the DRAGON environment via proxy hosts
- Register the media device (camera, display, ...)
- Sink and source signaling protocols
- Provide Authentication, authorization and accounting.

**LDK-6000**

**DRAGON**
** ****Network**

**SMPTE-292**

**NARB**

**o/e**

** ****e/o**

**d/a**

**e/o**

** ****o/e**

**d/a**

**SMPTE-292**

**proxy**

**NARB**

**proxy**

## Low Latency Visual Area Networking

**Low Latency Visual Area Networking**

**IP network**

** ****Directly share output of visualization systems across high performance networks.**
** ****DRAGON allows elimination of latencies associated with IP transport.**

**DRAGON**
** ****Network**

**o/e**

**e/o**

**a/d**

** ****3D video/IP**

** ****3D video/IP**

**d/a**

## Status to Date

- Wavelength Selective Switch staged at UMD
- GMPLS control plane operational (Jan 04)
- Currently deploying fiber ring –
- Characterization in progress, Exp operational by Aug 31, 2004
- Optical peering issues being worked out with ATDNet.
- MIT Haystack being optically re-attached to DRAGON via BOSnet
- Initial VLSR functionality demonstrated
- Successful interop tests with across Movaz, Juniper, Sycamore, Ethernet switches.  More to come...
- Currently extending the KOM-RSVP to include full GMPLS label set
- VLSR being used in other testbeds: CHEETAH, HOPI and USN are interested...
- Expect to begin inter-domain testing of initial NARB between ATDnet and DRAGON.
- Plans being made to extend DRAGON to NLR and begin inter-domain experiments with Omninet, HOPI, USN, and others.

## Issues

- Common Service Definition(s) needs to be developed
- What are the semantics of the service parameters communicated between domains? E.g. if I request an “ethernet” label, can I assert spanning tree protocols across it? Or does it simply mean ethernet framing at the handoff?
- Common scheduling and advance reservation protocol across domains
- Are GRID scheduling algorithms and tools adaptable to network resources? Do we need different tools for the network portion?
- How does the network verify that the desired performance specifications are being provided?
- Often long distance connections transit multiple Nes that impose unexpected constraints
- Privacy and security – How do we protect the control plane? What aspects do we need to worry about?