Transcript Proposed future direction for CHEETAH

Proposed future direction
for CHEETAH
Malathi Veeraraghavan
University of Virginia
August 9, 2006

Outline

What's our goal for the network:

eScience network or large-scale GP network?

Book-Ahead (BA) or Immediate-Request (IR)?

CHEETAH network evolution to support IR

Software modules that need to be implemented

Applications

CHEETAH/DRAGON/HOPI interconnectivity
1
eScience or GP? BA or IR?
BA
IR
eScience
networks
very large file transfers need
high-BW and long holding time
+ remote viz. need to reserve
timeslot for other resources
None?
general-purpose
networks
circuit service to service
providers - users are only
administrators
- router-to-router circuits
circuit/VC service for end
users
- host-to-host + router-torouter (E2E)
- partial-path router-to-router
circuits on congested links
(called in by end user)
2
Reasons for choosing IR

Metcalfe's value statement


IR seems more natural in data world



SCALE, SCALE, SCALE
Bandwidth not as scarce as airline seats that only BA
can be supported; so IR seems like a must-have
Cisco/Juniper/Sycamore control-plane
implementation + community's standardization
effort is "wasted" to a large extent with BA
Shouldn't at least one testbed to study whether
and, if so, how, IR bandwidth-management
software built into switches can be useful
3
Co-management of bandwidth
on IR and BA basis

But, BA and IR cannot coexist without
bandwidth partitioning


BA allows for high-BW, long-duration calls
IR calls will suffer a high call blocking rate if
supported through BA scheduler
4
CHEETAH wide-area network
UVa
Raleigh PoP (MCNC)
SN16000
via NCREN
OC192 Control GbE/
card
card
10GbE
card
CUNY
NCSU
End hosts
OC-192 (via NLR/SLR/NCREN)
ORNL PoP
SN16000
End hosts
Atlanta PoP (SOX/SLR)
SN16000
GbE/ Control
OC192
10GbE card
card
card
OC192 Control GbE/
10GbE
card
card
card
End hosts
OC-192
ORNL
GaTech
5
What CHEETAH s/w enables now.
VT
UVa
Cville, VA mvstu6
UGa
GbE circuit
zelda2
Gatech
duke
CHEETAH
Atlanta, GA
wukong
UN
C
Releigh, NC
ORNL, TN
zelda4
NCSU
UT
Once zelda2's GbE card
is LOCKED in a circuit headed to mvstu6,
X. Fang
it cannot communicate with wukong or zelda4 via CHEETAH
R. Gisiger
6
Network evolution to support IR

Current CHEETAH network only supports
10 circuits per OC192 link


IR mode inefficient if m, the link capacity in
channels, is small (i.e., 10)
Recoup OC1-crossconnect capability of the
SN16Ks from its current 1Gbps use

Has three advantages



supports higher m; better for IR
GMPLS standards based signaling (GbE-SONET
signaling is Sycamore proprietary)
Call setup delay: 166ms for two-hop instead of
1.5sec!
7
Network evolution options

Four options:




NICs with VLAN support PLUS VLSR for SN16K
with control-plane support for VLANs
15454 with VLSR
IP router with VLSR
Ethernet switch with VLSR
8
NICs with VLAN support



Useful for web caching application since a
cache may need to talk simultaneously to
two other caches
In general useful for end-to-end circuits
(whether router-to-router or host-tohost)
BUT, since the SN16K GMPLS software
does not support VLAN mapping to
multiples of OC1s, this solution is
insufficient; hence the next slide
9
SN16K/VLSR at each PoP



Can write a VLSR for SN16K to support
GMPLS control of VLAN-OCxx circuits and
then use VLAN-capable NICs
Use hdb commands for flow-based
Ethernet service, i.e., to map VLANs to
OCxx circuits, but hdb software is
unsupported
Beats the reason for our choice of SN16Ks
(GA support of GMPLS control plane)
10
15454/VLSR at each PoP



Make the 15454 serve as the intermediary
between Ethernet NICs in hosts and SONET
based SN16Ks at cheetah PoPs
Useful for end-to-end circuits (whether routerto-router or host-to-host), e.g., webcaching.
Two problems:



Needs a heterogeneous signaling procedure, Intserv
based Path message and VLAN IDs as labels to a
SONET based Path message and SKULM labels
VLAN ID continuity requirement
Cannot support partial-path circuits
11
IP router/VLSR at each PoP




Use OCxx SONET interfaces to connect
IP router to SN16K
Connect web caches to router
Have router initiate pure SONET circuit
setup
Use PBR or just ordinary routing table
update to map flows to different OCxx
circuits; support multiple circuits from one
web cache
12
IP router/VLSR at each PoP

Can support end-to-end circuits






web caching
CDN servers
router-to-router apps:
 administrator initiated increases
 SNMP log monitor initiated increases
video apps at 10-15Mbps - map to one OC1
Has the potential to support PPCs (partial-path
circuits)
Place router with VLSR in enterprises at edge of
GbE cheetah access link
13
Ethernet switch/VLSR at each PoP

Does not help with the problems noted in today's
Gb/s circuit use of the SN16K





long call setup delays: 1.5sec
non-standard solution
high per-circuit BW
Using an Ethernet switch/VLSR at an enterprise
(e.g. CUNY) requires all VLANs sharing 1Gbps
CHEETAH access link to be switched to the same
exit SN16K.
Even worse, m=1 if whole 1Gb/s link used for a
circuit
14
Software modules required



CVLSR for IP router
Web caching & video apps
CTCP code to support multiple
simultaneous flows
15
Applications

In order of preference:



web caching
video apps at 10-15Mbps - map to one OC1
router-to-router apps:



storage


administrator initiated increases
SNMP log monitor initiated increases
Contact: Paul Sheldon, Vanderbilt, has NSF MRI to
install data depots (600 TB)
CDN servers

IEEE, ACM, ComSoc web sites
16
Equipment purchase



IP routers with channelized SONET cards with GA GMPLS
UNI implementation at each CHEETAH PoP
IP routers with GbE blades at enterprises
IP router in NLR McLean (fourth CHEETAH PoP)



unless MAX/Dragon router is available - then buy GbE and
OC192 blades for that router
If NC 454 transponders are unavailable, purchase
transponders for DC-Raleigh NLR link - since HOPI
doesn't have this
Colocation costs at NLR McLean and NLR Raleigh
17
DRAGON

How many WDM channels per link?





Heterogeneous circuit setup not advisable in IR
mode:


m has to be small due to transponder costs
makes it hard to support IR
hence the interest in BA
GMPLS in Movaz switches useful only for provisioning
but not BW sharing
should provision fat pipes based on aggregate usage
observation, not per small-BW VLAN
Does each DRAGON PoP have an Ethernet VLAN
switch with VLSR?
18
Interest in using CHEETAH as part
of the Southern leg for HOPI


HOPI is public-domain "commercial"
Further HOPI uses VLAN switches - small
granularity!

CAC even w/o enforcement is fine if CTCP is
the only conduit at end hosts - can enforce
there
19
HOPI and web caching



Seems like a good match
Rick's black cloud experiment - same as
web caching
Also Rick wants the "hybrid" part to be
exercised - here's how with IP and
VCs/circuits
20
What am I asking Rick?


Web caches at PoPs
Permission to run router VLSR software on
Abilene routers that will need to update
routing tables!

Will of course demo this first thoroughly on
cheetah network
21
What am I asking Jerry?


CVLSR on HOPI switches - hop-by-hop IR mode
IR support - GMPLS peer model



call setup Path message between router VLSRs (in
different domains) will carry final dest. IP address
Router VLSR within cheetah (HOPI) domain finds exit
router for that domain and issues SONET circuit Path
message with that exit router as destination
Web caches at DRAGON PoPs
22
Interconnect CHEETAH, DRAGON
HOPI



Through IP routers of Cheetah & Abilene
With our IP router/VLSR combo, setup
router-to-route SONET OC1 circuits via
cheetah and router-to-router VLAN virtual
circuits through DRAGON/HOPI. At
routers, do PBR mapping for flows or just
update routing tables for destination IP
addresses (data-plane
This means packets go back to IP layer
between two networks
23
Figure

HOPI + CHEETAH with routers in between
24
Web caching example

Example: web cache in CA to web-cache at
ORNL


VLAN from Sunnyvale Abilene router through
five HOPI nodes to McLean router
McLean router to ORNL router through
SONET nodes
25