Scoping the work

Initial thoughts

Basic Dataplane Model

• Single nailed-up path

Sender(Talker)

NIC

NIC

Flow ID

Receiver(Listener)

Per-Flow State

Dataplane Model

• Add Replication & Elimination for resiliency

Sender(Talker)

NIC

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

Reservationrequest

Sender(Talker)

NIC

NIC

Flow ID

Receiver(Listener)

Reservations from Controller

Sender(Talker)

User/app/

service

NIC

NIC

Per-Flow State

TSpec

User/app/

service

Controller

Flow ID

?

Service (northbound) interface

Receiver(Listener)

?

?

UNIinterface

Control (southbound) interface

UNIinterface

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?