NSLP for Quality of Service

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 reservationReceiver-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