DRAGON Dynamic Resource Allocation via GMPLS Optical Networks Presented to the NASA Optical Network - PowerPoint PPT Presentation

1 / 34
About This Presentation
Title:

DRAGON Dynamic Resource Allocation via GMPLS Optical Networks Presented to the NASA Optical Network

Description:

US Naval Observatory (Wash., DC) University of Maryland College Park (UMD) ... Current methods still incur generally two days to capture and move the data to ... – PowerPoint PPT presentation

Number of Views:407
Avg rating:3.0/5.0
Slides: 35
Provided by: nren
Category:

less

Transcript and Presenter's Notes

Title: DRAGON Dynamic Resource Allocation via GMPLS Optical Networks Presented to the NASA Optical Network


1
DRAGONDynamic Resource Allocation via GMPLS
Optical NetworksPresented 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
2
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

3
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

4
End to End GMPLS TransportWhat is missing?
IP/ Ethernet, sonet, wavelength Core services
No standardized Inter-Domain Routing
Architecture, including transport layer
capability set advertisements
GMPLS-OSPF, ISIS-TE intra-domain routing
GMPLS-RSVP-TE signaling
No end-to-end instantiation
IP/Ethernet campus LAN
Integration across Non-GMPLS enabled networks
No Simple API
5
The DRAGON ProjectKey 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

6
DRAGON ArchitectureAll Optical Core and Edge
2R OEO Transponders allow multiple device
interface types gige, hdtv(smpte292), vis cluster
Optical Edge
Optical Core
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
7
Technical Issues
8
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

9
Network Aware Resource Broker (NARB) Functions
IntraDomain
IGP Listener Edge Signaling Enforcement
Authentication Path Computation ASTDL
Induced Topology Computations Accounting
Scheduling Authorization (flexible policy
based) Edge Signaling Authentication
NARB
Edge Signaling Authorization
ASTDL Scheduling Authentication Authorization Acco
unting
IP Control Plane
Signaling
End System
End System
AS
Data Plane LSP
Ingress LSR
Egress LSR
Data Plane
10
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

Transport Layer Capability Set Exchange
NARB
NARB
NARB
End System
End System
AS 1
AS 3
AS 2
11
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.

12
VLSR Abstraction
OSPF-TE / RSVP-TE
OSPF-TE / RSVP-TE
?
LSR
LSR
Ethernet network
GMPLS network
13
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 applications network
    requirements, service validation and performance
    verification can be performed (wizard gap
    issues)

14
Application Specific Topology Description
Language - ASTDL
Correlator
Concept
  • mkiv.oso.chalmers.se

corr1.usno.navy.mil
  • pollux.haystack.mit.edu

GGAO telescope
Haystack telescope
  • ggao1.gsfc.nasa.gov

Chalmers telescope
Instantiation
Formal Specification
Datalink TypeEthernet bandwidth1g Source
Address1vlbid DestinationAddress2
Topo_vlbi_200406 Correlatorcorr1.usno
.navy.milvlbid // USNO
DataLink( mkiv.oso.chalmers.se, Correlator )
// OSO Sweden DataLink( pollux.haystack.mit.e
du, Correlator )// MIT Haystack DataLink(
ggao1.gsfc.nasa.gov, Correlator ) // NASA
Goddard C Code invocation example eVLBI
new ASTDLTopo( Topo_vlbi_200406) // Get
the topology definition Stat eVLBI.Create()
// Make it so!
15
The AST Process
Master
16
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(argv1) if(topo NULL) exit(1) stat
topo-gtResolve() if(stat ! 0) exit (2)
stat topo-gtInstantiate() if(stat ! 0)
cout ltlt "Error stat" ltlt stat ltlt endl
exit(3) stat topo-gtUserHandoff() stat
topo-gtRelease() exit(0)
Read topology definition source and create the
Topo object
Resolve hostnames and other service specific data
Establish all the connections
exec() the user and pass off the connections.
All done. Tear it down.
17
DRAGON Network
18
DRAGON NetworkWashington, DC Metro Area
GSFC
CLPK (College Park, MD)
Haystack
UMD
USNO
DCNE (Qwest)
DCGW (GWU)
ATDnet/BOSSnet
ARLG (Arlington, VA)
MCLN (Level3)
Abilene
NLR/HOPI
ISI East
ACCESS
19
Commercial PartnerMovaz 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
20
Movaz PartnershipNew 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

21
Initial Applications
22
Very Long Baseline Interferometry (VLBI)
23
Very Long Baseline Interferometry (VLBI)
24
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
    thats too long.
  • Why are ltRealtime Near RT on-demandgt
    resources so important to this application?

25
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
    earths shape due to glacial rebound from the ice
    age, etc.
  • Most notably, VLBIs 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.

26
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 demod
    in April 2004)

27
electronic-Very Long Baseline Interferometry
(e-VLBI)
  • electronic-Very Long Baseline Interferometry
    (e-VLBI)
  • MIT Haystack
  • NASA GSFC (GGAO)
  • USNO
  • Radio Telescopes reachable via Abilene
  • eVLBI Experiment Configuration

28
DRAGON eVLBI Experiment Configuration
29
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

30
Uncompressed HDTV-over-IPCurrent Method
LDK-6000
PDP-502MX
850Mbps RTP/UDP/IP
SMPTE-292 HDTV output 1.485 Gbps
network
Astro 1602 DAC
  • Not truly HDTV --gt color is subsampled to 8bits
  • Performance is at the mercy of best-effort IP
    network
  • UltraGrid processing introduces some latency

31
Low latency High Definition CollaborationDRAGON
Enabled
LDK-6000
proxy
proxy
SMPTE-292
e/o
d/a
o/e
d/a
o/e
e/o
SMPTE-292
DRAGON Network
NARB
NARB
  • 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.

32
Low Latency Visual Area Networking
3D video/IP
IP network
3D video/IP
DRAGON Network
o/e
d/a
e/o
a/d
  • Directly share output of visualization systems
    across high performance networks.
  • DRAGON allows elimination of latencies
    associated with IP transport.

33
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.

34
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?
Write a Comment
User Comments (0)
About PowerShow.com