[Nsi-wg] call tomorrow -May 8

[Sebastien Soudan]

Hello, 

Please find with this mail our proposition. This is still a draft and
has to be completed/clarified/...

Unfortunately I won't be able to attend May, 8 phone call as it is a
legal holiday in France and I will not be available. I would be happy to
exchange about this by mail and maybe at next call.
I also propose to make a short presentation about this at next wg
meeting.

Regards, 
Sebastien

On Wed, 2009-05-06 at 00:18 -0400, John Vollbrecht wrote:
> We will have a call tomorrow morning Wed 5/8 at 9AM ET.  Call  
> information is
> 
> Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013  
> (toll free US/Canada Only)
> Enter access code: 0155180
> 
> possible agenda -
> 
> NSI meeting last week
> continue discussion of architecture strawman doc
> update on contributions
> 
> 
> John Vollbrecht
> Senior Network Engineer, Internet2
> office 734 352 4960 cell 734 395 7890
> 
> 
> 
> 
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-- 
Sebastien Soudan, PhD student
INRIA RESO, Laboratoire de l'Informatique du Parallélisme
ENS-Lyon, 46 allée d'Italie, 69364 Lyon, France
http://perso.ens-lyon.fr/sebastien.soudan/
-------------- next part --------------

#title Network Reservation


* Network Model

** Resource description:
Domains are made of:
 - _Ingress points_: {ip}
 - _Egress points_: {ep}
 - _Reservable services_: {(ip,ep, service_description)}

** Reservable Service's description:
 - minimum duration
 - maximum duration
 - bandwidth granularity
 - minimum bandwidth
 - maximum bandwidth
 - supported technologies
 - minimum notification delay
 - supported reservation types


* Network Requests
We define a request as:
   ((src, tech), (dst, tech), time_constraints, type, constraints)

** Common attributes:
  - =((src,technology), (dst,technology))=

** Time constraints:
  - **tn**: limit for notification 
  - **tf**: limit for final version
  - **ts**: start time
  - **te**: end time

** Types:
  - **C**: connectivity service
  - **P**: provisioned service
  - **M**: malleable service

** Network constraints specification:
We define 3 kind of services that users can request:

***  **Connectivity service** 
   - loss rate
   - delay
   - buffer size (buffer at Customer Edge)

***  **Provisioned service**
   - rate 
   - buffer size (buffer at Customer Edge)
   - delay
   - loss rate

***  **Malleable service**
   - volume
   - minrate (could eventually be a function of time)
   - maxrate (same)
   - buffer size (buffer at Customer Edge)
   - delay
   - loss rate
   - objective: mct, ...


* Reservation States
For each reservation, we define the following states, transitions and
semantic of each state (what can be assumed regarding the request when
it is in a given state). Some of the states can not be changed once
reached: terminal state.

** States
 - _new_
 - _scheduled_
 - _granted_
 - _running_

** Terminal states
 - _rejected_
 - _terminated_
 - _error_

** Semantic
 - _new_: no decision regarding this request/transfer has been made.
 - _scheduled_: request will be accepted but the definitive allocation
   of resources is not known.
 - _granted_: request is in its definitive form, no change will occur regarding the allocation.
 - _running_: transfer is running.
 - _rejected_: request has been rejected and transfer
   won't happen. This state is only reachable from "new" state.
 - _terminated_: transfer is finished.
 - _error_: this state is reached when an error (transition not
   described above) occur.

** Allowed Transitions
  - _new_ -> _rejected_ 
  - _new_ -> _scheduled_
  - _scheduled_ -> _granted_
  - _granted_ -> _running_
  - _running_ -> _terminated_

* Negotation Process
Negotation process needs, first, a information service to find the
description of the available network service and local constraints. And then 
a submission interface.

** Resource Discovery:
 Each domain expose its own list of services.
 Interlinks must also be exposed.

** Three-way reservation process:
 This is based on the three following steps:
  - (1) request submission
  - (2) notification of acceptability from the service
  - (3) confirmation from the client

  This allows to service composition by the client. It has to be 
  constrained by time to avoid locking.

*** Description:
  _(1) Submission:_
  User submit the request to the service.

  Request issued by client:
   ((src, tech), (dst, tech), Time_constraints, type, constraints)

  _(2) Notification:_
  Then service send (at least make it available) its decision to user
  within the time constraint.
  This allows users to consider another network service if this one
  fails to reply within the time constraints.
  Notification sent back to the client is :
  =(price, deadline_for_confirmation (tc) )=
  Notification of acceptance/rejection must comes before tn as given
  in time_constraints part of the request.

  _(3) Confirmation:_
  User must confirm he still wants what he asked before
  tc (specification in notification message).

  _(4) Grant:_
  Service has time to optimize the allocation and modify it as long as
  it satisfies the constraints specified by the request. Allocation
  can still be modified by the service until date tf as specified in the request.