Scoping the work Initial thoughts

Basic Dataplane Model Single nailed-up path Sender (Talker) NIC Flow ID Receiver (Listener) Per-Flow State

Dataplane Model Add Replication & Elimination for resiliency Sender (Talker) NIC Flow ID Receiver (Listener) Per-Flow State

In-band reservations Control (southbound) interface User/app/ service Per-Flow State TSpec User/app/ service Controller Service (northbound) interface ? Topology, resources Reservation request Sender (Talker) NIC Flow ID Receiver (Listener)

Reservations from Controller Sender (Talker) User/app/ service NIC Per-Flow State TSpec User/app/ service Controller Flow ID ? Service (northbound) interface Receiver (Listener) ? ? UNI interface Control (southbound) interface UNI interface

Pieces to be looked at #1 Interactions models and Architecture – Service/application reservations at the top – Controller to devices Topology and resource discovery Path and resource provisioning can be in-band or hub and spoke Endpoint interaction? – UNI (interaction between NICs and network) Path up/down notifications?

Pieces to be looked at #2 Data models and their semantics – Per flow state and per hop behavior Common with IEEE 802? Common data model? Queues, buffers, timing, schedules – Flow identification for L3 use Implicit aka 5-tuple might have issues with splitting Some explicit flow identification needed; flow tag, seqno, timestamp? – Application-centric – at NB interface Tspec (flow characterization) – does it need reliability information to set up splits? Receiver interest? To controller vs. sender?