1. NSLP for Quality of Service
draft-ietf-nsis-qos-nslp-03.txt
Sven Van den Bosch (ed)
Georgios Karagiannis
Andrew McDonald
(et al)

2. Changes from –02 version Addressed comments from early review
Added text on receiver-initiated and bi-directional reservations
Extended description of session binding
Added support for fate sharing
Restructured message formats and processing section
Clarified refresh reduction mechanism
Added assumptions on QoS model
Added assumptions on operating environment

3. Receiver-initiated reservation
Current proposal
Use QUERY to set up reverse path state
Use QUERY to gather path information (OPWA)
Use QUERY to refresh reverse path state
Question 1: Does QUERY need to carry QSPEC?
It is optional in case OPWA is not needed
Question 2: Does QUERY need to carry RESPONSE_REQUEST?
It is not used when QUERY acts as an RSVP PATH message
If ‘no’ on both questions
Do we need a separate (NULL) message for this ‘empty’ QUERY?
Trade-off between QUERY complexity and additional message type
Is the NULL message generally useful across NSLPs?
Question 3: Should GIMPS be responsible for refreshing reverse path state?

4. Bi-directional reservation
Current situation: two supported mechanisms
Sender-initiated reservation+Receiver-initiated reservation
Two sender-initiated reservations
What happens when following conditions apply
One of the end nodes does not have sufficient information, and
(some part of) the network does not install reverse path state
Question: Do we want to provide a solution for this situation?
Proposed solution: Carry necessary information (opaquely) in forward direction
Bundling of NSLP messages
Provide indication to wait for subsequent NSLP messages before sending?

5. Session binding (example)
Aggregate reservations
If session B is torn down then session A may be torn down as well but not vice versa
QNI
QNE
QNE
QNR
End-to-end session
= ‘binding session’
SESSION_ID = A
End-to-end session
= ‘binding session’
SESSION_ID = A
BOUND_SESSION_ID = B
Aggregate session
= ‘bound session’
SESSION_ID = B

6. Session binding (example)
Bi-directional reservations
End-to-end session (XY)
SESSION_ID = A
BOUND_SESSION_ID = B X
QNE
QNE Y
End-to-end session (YX)
SESSION_ID = B
BOUND_SESSION_ID = A

7. Special ‘refresh’ cases
New message with same SESSION_ID and different MRI
Default behaviour: Reservation is replaced
Exception: NO_REPLACE flag set
Enter into resource sharing cases
New message from a bound session
Default behaviour: all binding sessions share fate
Exception: NO_FATE_SHARING flag set
Only end/edge points use fate sharing information

8. Resource sharing Current situation
Resource sharing applies to sessions with same SESSION_ID, different MRI and NO_REPLACE flag set
Resource sharing is requested by QoS NSLP processing or RMF; Required information is contained in QSPEC
Question 1: Should it also apply to bound sessions? [Yes]
Question 2: What mathematical operations are useful on two or more reservations?
ADD, SUBTRACT, …
Question 3: Do any of these have impact on QoS NSLP?
If yes, the impact is independent of session binding

9. Reserve/commit functionality
Alignment needed
QoS NSLP: qualitative (commit flag)
QoS model: quantitative (start/stop timing)
Is this a QoS NSLP issue anyway?

10. Priority Mailing list discussion
Reservation priority (preemption) is not a QoS NSLP function (see section 4.5)
Message priority is in scope for the QoS NSLP but relies on GIMPS (see section 7.7)
Question 1: Required number of levels for message priority?
Question 2: Is reservation priority applicable to different NSLPs? Should there be an generic NSLP priority object?

11. Refresh overhead reduction
Current proposal:
Insert RESPONSE_REQUEST (to confirm state installation)
Refer to reservation with SESSION_ID and RSN
So, still one refreshing RESERVE per reservation
But smaller and possibly easier to process
Question: Should we be able to send a RESERVE without MRI (and only pass MRI over the API)?

12. Mailing list Issue on use of SCOPING in RESPONSE
Need to clarify global RII significance versus local RSN significance
Proposed solution
Use SCOPING only in QUERY/RESERVE
make RII a separate object, carried in QUERY/RESERVE and RESPONSE

13. Next steps Implement interim meeting outcomes Complete Error codes AAA
Security