1. Inder Monga Co-chair, OGF NSI-WG
NSI Interim face to face meeting Co-located with GLIF/APAN, Hong Kong 23rd Feb 2011
Inder Monga
Co-chair, OGF NSI-WG

2. Agenda 9am - 12:30 pm NSI Connection Service discussion – review:
Agree connection service decision points (Guy)
Agree set of message primitives (Inder)
Connection Service state machine for the NSI message exchange (Inder)
2 pm - 4 pm
Agree set of parameters associated with each primitive (Guy – Jerry?)
Service definition (how to use with protocol) (Jerry)
STPs (Tomohiro)

3. Connection Service Message Primitives
Reserve
Request:
Direction: RA  PA
Purpose: Make a request to reserve network resources for a connection between two STP’s constrained by a certain service parameters
Response: Direction: PA  RA
Confirmed
Purpose: The request to reserve the resources has been granted [includes segmentation]
All children
Failed
Purpose: The request to reserve the resources could not meet the requested service parameters, may include error reason
Means there are no residual children reservations anywhere in the system

4. CS ID discussion *agreed among JM, TK, GR, HT, JS, AT, IM
Each NSA has a globally unique ID = NSA_ID RA generated Request ID to identify a connection service conversation must be unique within a given NSA = REQ_ID Unique identification of the conversation is a combination of the RA generated request ID and the RA NSA identifier that generated the request = REQ_ID + NSA_ID = CS_Instance_ID No requirement for the RA generated ID to be globally unique There is a field in the message structure for optional use that an RA or PA can use to globally identify a connection. Its use is not mandated by the protocol so is an optional field Note: You can have multiple connection service requests between the same RA-PA pair for the same connection request*****

5. Connection Service Message Primitives
Provision
Request:
Direction: RA  PA
Purpose: PA has been given permission to setup the reservation on RA’s behalf subject to the constraints of the requested service
Response: Direction: PA  RA
Confirmed
Purpose: The provisioning of the resources has been completed [includes children]
Failed
Purpose: The provisioning of the resources could not be completed, self or children

6. Provisioning Failure discussion
When a child fails their provisioning, the child PA sends an Provisioning failure message to the corresponding RA The RA notifies the Aggregator Function in the NSA. The Aggregator function may try to recover, if cannot, it will release all children and generate a provisioning failure event to its PA That PA will send a provisioning failure up to its parent RA, and this process will do the same recursively till we get to the ultimate parent RA The ultimate RA will, based on the internal policy function, decide to do something - possibilities including terminating the reservation with cancel or trying alternatives. What the ultimate RA does is out of the scope of the protocol discussion

7. Connection Service Message Primitives
Release
Request:
Direction: RA  PA
Purpose: PA should release the provisioned resources without removing the reservation.
Confirm
Direction: PA  RA
Purpose: The releasing of the resources is done
Fail
Purpose: The releasing of the resources failed
Informational message, and stay in releasing state

8. Connection Service Message Primitives
Cancel
Request:
Direction: RA  PA
Purpose: PA should release the provisioned resources and cancel the reservation.
Confirmed
Direction: PA  RA
Purpose: The releasing of the resources is done

9. Connection Service Optional Message Primitives
Query
Request:
Direction: RA  PA
Purpose: Mechanism for either agent to query the other agent for a set of connection service instances between the RA-PA pair. This message can be used as a status polling mechanism.
This is a management function for CS
Response
Direction: PA  RA
Purpose: The query information in a structured output as defined.

10. Query discussion
Not historical in nature. Only for currently active connections If the connection does not exist, it returns the information that it does not exist Query serves the function of recovery if the notification service has an error. It serves as the management function for the CS

11. Connection Service Optional Message Primitives
Notify
Direction: RA  PA or PA  RA (?)
Purpose: Informational message of notifying events mainly errors

12. Connection Service Optional Message Primitives
Modify
Request:
Direction: RA  PA
Purpose: Mechanism for RA to request a change in service definition while the reservation/connection service is in progress. The parameters allowed are ones that can be implemented without changing the state of the connection if it is in service
It is fine for PA not to implement this, and ignore/reject the modify message
Granted
Direction: PA  RA
Purpose: The query information in a structured output as defined.
Not Granted
Purpose: Not accepted, reason for rejection

13. State Machine for NSI

14. Recapping the discussion of the past few months
State machine for the Connection Service lifecycle (Artur)
Captures all service features like auto-start, manual start, on- demand reservation
Modified state machine for CS lifecycle (Berkeley)
Connection Message exchange lifecycle (Arlington)
Discussion on the phone calls with open questions
State machine for messages = message exchange flow
Does not capture the service, is there a need for a “guidance” on service state machine?
Define the NSA requirements from a service perspective in the document
What else is needed to be defined for interoperability?

15. PA/RA state machines which only handle message exchange and sequence (no behavior of NSA are modeled in the SM)
NSA
RA SM
NSI messages
NSA
PA SM
Input/output internal to an NSA
RA SM
RA SM
NSA
NSA
PA SM
PA SM
NRM
Slides from
Tomohiro
RA SM
NRM

16. Requestor Agent (RA) messaging state machine
Initial
Provisioning
>reserve_start
>rsv.rq
>provision_start
>prov.rq
<prov.cf
<provision_complete
Reserving
Reserved In
Service
<prov.fl
<provision_failed
<rsv.gr
<reserve_ok
<rel.cf
<release_complete
>release_start
>rel.rq
Releasing
<rsv.ng
<reserve_ng
Not necessary?
Terminated
Canceling
Any
state
<cncl.cf
<cancel_complete
>cancel_start
>cncl.rq
red : an input/output event which is an NSI message
blue : an input/output event which is not an NSI message
>: Downstream input/output
<: Upstream input/output
rsv: reserve, prov: provision, rel: release, cncl: cancel
.rq : request, .cf: confirm, gr: granted, ng: not granted
Input
Output
RA SM

17. Provider Agent (PA) messaging state machine
Initial
Provisioning
>rsv.rq
>reserve_start
>prov.rq
>provision_start
<provision_complete
<prov.cf
Reserving
Reserved In
Service
<provision_failed
<prov.fl
<reserve_ok
<rsv.gr
<release_complete
<rel.cf
>rel.rq
>release_start
Releasing
<reserve_ng
<rsv.ng
Not necessary?
Terminated
Canceling
Any
state
<cancel_complete
<cncl.cf
>cncl.rq
>cancel_start
red : an input/output event which is an NSI message
blue : an input/output event which is not an NSI message
>: Downstream input/output
<: Upstream input/output
rsv: reserve, prov: provision, rel: release, cncl: cancel
.rq : request, .cf: confirm, gr: granted, ng: not granted
Input
Output
PA SM

18. Modify Message Modify In Service Modify Reserved Other states
<modify.ok
<modify.granted
<modify.ok
<modify.granted
Modify In
Service
Modify
Reserved
>modify.rq
>modify.start
>modify.rq
>modify.start
<modify.ng
<modify.ng
Other
states
>modify.rq
<modify.ng

19. Other characteristics of the Connection Service?
The end-user looks at the service holistically
Where do we specify the following service characteristics?
Time components: On-demand, Advanced Reservation
Control component: Auto-start, Manual start
Need a service plane state machine along with the messaging state machine
Allow people to innovate on top of the messaging within their software without breaking the NSI CS paradigm
Questions for the group
Standardize the above behaviors for interoperability?
What minimum set of features are must-implemented?
Are service providers allowed to have optional ones or new services within the framework?

20. Example: NS with Ultimate Requester(UR), Ultimate Provider(UP) and Aggregator (AG)
NSA UR
RA SM
NSA
PA SM AG
RA SM
RA SM
NSA
NSA
PA SM
PA SM AG UP
NRM UP
RA SM
NRM

21. Sample Ultimate Provider with NSI messages
>rsv.rq, (reservation ok)
<rsv.ok
(start_time)
(provision)
<prov.cf
>prov.rq
Initial
Scheduled
Auto
Start
(start_time)
(start_time, provision_failed)
<prov.fl
>prov.rq (provision_failed)
<prov.fl
>prov.rq (provision_succeed)
<prov.cf
Idle In
Service
>rsv.rq, (reservation ng)
<rsv.ng
>rel.rq
(release) <rel.cf
(end_time)
(cancel)
>cncl.rq
(cancel) <cncl.cf
Any
state
Terminated
(end_time)
(release) (cancel)
Not necessary?
red : an input/output event which is an NSI message
>: Downstream input/output
<: Upstream input/output
rsv: reserve, prov: provision, rel: release, cncl: cancel
.rq : request, .cf: confirm, gr: granted, ng: not granted
(event): internal event
,: “all” condition
Input
Output

22. Sample Aggregator function with NSI messages
Initial
Provisioning
>rsv.rq
>rsv.rq*
>prov.rq
>prov.rq*
<prov.cf*
<prov.cf
<rsv.cf*
<rsv.cf
Reserving
Reserved In
Service
<prov.fl&
<prov.fl
>rel.rq*
<rel.cf*
<rel.cf
>rel.rq
>rel.rq*
<rsv.ng&
<rsv.ng
>cncl.rq*
Releasing
Not necessary?
Terminated
Canceling
Any
state
<cncl.cf*
<cncl.cf
>cncl.rq
>cncl.rq*
red : an input/output event which is an NSI message
>: Downstream input/output
<: Upstream input/output
rsv: reserve, prov: provision, rel: release, cncl: cancel
.rq : request, .cf: confirm, gr: granted, ng: not granted
*: for input, receive from all children
for output, send to all children
&: received one or more rcv.ng
Note: here, downstream agent is assumed to return cncl.cf (or ignore cncl.rq for the orange case) if there is no corresponding reservation.
Input
Output

23. Error Scenarios Two main error classes
The service fails to meet the committed service characteristics
Either RA or PA becomes unreachable to exchange CS messages
Thoughts on error handling philosophy
If cannot meet committed service characteristics
Release or Cancel the connection, depending on the situation
Includes scenarios where the service request is response exceeds expected time.
How and Why?
If RA or PA becomes unreachable
Depends on the state and the message
Could result in one side clearing the state machine
How does the other side recover and synchronize?

24. Message delivery error
The underlying reliable transport is not able to deliver the message
Error notification by underlying transport layer
Assumption
Error code, if included, provides guidance on the option to pursue
Options
Retry for N number of tries, wait for T time each retry
Generate an internal state machine event, and transition to a stable state
Provider suggested cancel? (notification or explicit)

25. Service Failure Possible Reasons Data Plane failure
Fiber cut, maintenance mode, router failure
Duration of failure
Transient
Long-term
Place of detection
Intermediate NSA (PA/NRM combination)
Originating/Destination RA (Application/end-node)
Action
Transition to the closest stable state

26. Open issues for NSI and Connection Services protocol
NSI Transport protocol selection/specification [John Macauley,
Connection Service Protocol
Different “services” supported
On-demand, Scheduled, Auto-start, Manual-start etc.
Behavior needs to be defined and agreed upon
State machine
RA to PA
Service Tree processing
Primitives and messaging
Service Definitions
STP details (and connection to topology)
Error Handling
Identifiers
Prototype implementation
interoperability

27. Berkeley state machines

28. If we do not introduce PA/RA state machines, UR, AG, UP are modeled to directly send/receive NSI messages
NSA UR
NSA AG
NSA
NSA AG UP
NRM UP
NRM

29. Sample Ultimate Provider with NSI messages
>rsv.rq, (reservation ok)
<rsv.ok
(start_time)
(provision)
<prov.cf
>prov.rq
Initial
Scheduled
Auto
Start
(start_time)
>prov.rq
(provision) <prov.cf
>rsv.rq, (reservation ng)
<rsv.ng
Idle In
Service
>rel.rq
(release) <rel.cf
(end_time)
(cancel)
>cncl.rq
(cancel) <cncl.cf
Any
state
Terminated
(end_time)
(release) (cancel)
Not necessary?
red : an input/output event which is an NSI message
>: Downstream input/output
<: Upstream input/output
rsv: reserve, prov: provision, rel: release, cncl: cancel
.rq : request, .cf: confirm, gr: granted, ng: not granted
(event): internal event
,: “all” condition
Input
Output

30. Sample Aggregator function with NSI messages
Initial
Provisioning
>rsv.rq
>rsv.rq*
>prov.rq
>prov.rq*
<prov.cf*
<prov.cf
<rsv.cf*
<rsv.cf
Reserving
Reserved In
Service
<rel.cf*
<rel.cf
>rel.rq
>rel.rq*
<rsv.ng&
<rsv.ng
>cncl.rq*
Releasing
Not necessary?
Terminated
Canceling
Any
state
<cncl.cf*
<cncl.cf
>cncl.rq
>cncl.rq*
red : an input/output event which is an NSI message
>: Downstream input/output
<: Upstream input/output
rsv: reserve, prov: provision, rel: release, cncl: cancel
.rq : request, .cf: confirm, gr: granted, ng: not granted
*: for input, receive from all children
for output, send to all children
&: received one or more rcv.ng
Note: here, downstream agent is assumed to return cncl.cf (or ignore cncl.rq for the orange case) if there is no corresponding reservation.
Input
Output

31. Combination of Arlington and Berkeley state machines

32. Example: NS with Ultimate Requester(UR), Ultimate Provider(UP) and Aggregator (AG)
NSA UR
RA SM
NSA
PA SM AG
RA SM
RA SM
NSA
NSA
PA SM
PA SM AG UP
NRM UP
RA SM
NRM

33. Sample Ultimate Provider function
>reserve_start, (reservation ok)
<reserve_ok
(start_time)
(provision) <provision_complete
>provision_start
Initial
Scheduled
Auto
Start
(start_time)
>provision_start
(provision) <provision_complete
>reserve_start, (reservation ng)
<reserve_ng
Idle In
Service
>release_start
(release) <release_complete
(end_time)
(cancel)
>cancel_start
(cancel) <cancel_complete
Any
state
Terminated
(end_time)
(release) (cancel)
Not necessary?
blue : an input/output event which is not an NSI message
>: Downstream input/output
<: Upstream input/output
(event): internal event
start_time: start time timer event
end_time: end time timer event
,: “all” condition
Input
Output

34. Sample Aggregator function
Initial
Provisioning
>reserve_request
>reserve_request*
>provision_request
>provision_request*
<provision_complete*
<provision_complete
<reserve_complete*
<reserve_complete
Reserving
Reserved In
Service
<release_complete*
<release_complete
>release_request
>release_request*
<reserve_ng&
<reserve_ng
>cancel_start*
Releasing
Not necessary?
Terminated
Canceling
Any
state
<cancel_complete*
<cancel_complete
>cancel_start
>cancel_start*
blue : an input/output event which is not an NSI message
>: Downstream input/output
<: Upstream input/output
*: for input, receive from all children
for output, send to all children
&: received one or more reserve_ng
Note: here, downstream agent is assumed to return cancel_complete (or ignore cancel_request for the orange case) if there is no corresponding reservation.
Input
Output