NSLP for Quality of Service

Sven Van den Bosch (ed)Georgios Karagiannis

Andrew McDonald(et al)

draft-ietf-nsis-qos-nslp-03.txt

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

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?

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?

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 = ABOUND_SESSION_ID = B

Aggregate session= ‘bound session’SESSION_ID = B

Session binding (example) Bi-directional reservations

X QNE QNE Y

End-to-end session (XY)SESSION_ID = ABOUND_SESSION_ID = B

End-to-end session (YX)SESSION_ID = BBOUND_SESSION_ID = A

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

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

Reserve/commit functionality Alignment needed

QoS NSLP: qualitative (commit flag) QoS model: quantitative (start/stop timing)

Is this a QoS NSLP issue anyway?

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?

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)?

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

Next steps Implement interim meeting

outcomes Complete

Error codes AAA Security