Transcript QoS NSLP Open Issues

QoS NSLP Open Issues
Issue 35: Security
mechanisms and definitions

How much of the security and authorization
issues do we need to solve with the QoS
NSLP document?


Can we expect that GIMPS provides the level of
security required by the network operator?
If additional things are needed, those are for later
study, e.g., in RSVP POLICY_DATA and those
integrity objects were separate drafts. Similarly,
the current QoS NSLP draft talks about a
POLICY_DATA object. Should this be specified
somewhere else?

Would the NAT/FW and other NSLPs also need this?
Issue 17: Node failure and
restart handling

Need to consider what happens on
NSLP node failure.


E.g. resetting of RSNs.
Do we need some birthday/epoch
identifier?
Issue 27: Filters

Where and how are filters given?

To identify the flow(s) that should receive a
certain QoS.
Issue 30: ERROR_SPEC



Several issues here:
a) Why is a successful result returned using an
"error" object?
b) Need to co-ordinate the definition of the
ERROR_SPEC values with the other I-D authors


NTLP, other NSLPs, QSPECs
c) Many of the codes are clearly QPSEC-specific.

Suggestion: have a class for QSPEC-specific errors, and each
QSPEC specification defines its own error codes and
meanings
Issue 21: Tear


Should we use a 'T' bit in Reserve
message to identify a teardown
message: is it a message type too
costly?
Also, what is the exact operation of a
tear event, and where is it defined?

QoS NSLP or QOSM documents?
Issue 39: Explicit indication of
refresh


Should there be some concrete indication that
a RESERVE is a refresh for an existing state?
E.g. an "Explicit refresh“ bit in the common
header?
Some possible reasons:


On rerouting (or handover), useful to prioritise
existing sessions over new ones for admission
control
Easier processing on finding out that a RESERVE is
a refreshing RESERVE.
Issue 28: Different QUERY
messages

How to distinguish a generic QUERY
from one intended to trigger a receiverinitiated reservation?


Is the difference only if the RII is included,
or not?
If so, would it be better to have a clear
indication (1 bit) that the message is part
of the receiver-initiated signaling, and not
e.g. a protocol error.
Issue 25: Handling an
unknown QOSM/no resources


What really happens is some QNE does not
know the QSPEC, or does not have resources
available? How is the reservation in previous
nodes removed?
Is this actually a QSPEC issue?

If the resources are not available, the QNE sends
back an error message. Now, is it up to the
QSPEC/RMF to define what happens? That would
be best for the QoS-NSLP since the operation may
differ between QSPECs.
Issue 36: QOS-NSLP object for
security considerations




A cookie mechanism is needed to support security. Two objects
are foreseen:
A new object that can be seen as a Query cookie and that can
be inserted by an edge node (of a local QoS model) into any
incoming message that passes through an edge node.
A new object that can be seen as Response cookie that can be
inserted by an edge node (of the same local QoS model), that is
used as response to the Query cookie. This object could also be
included in any incoming message passing though this edge
node that is used as a response message (it could be a QoSNSLP RESPONSE or maybe a QOS-NSLP NOTIFY) and that is
sent towards the node that inserted the Query cookie.
The two above objects might be combined to form only one
object, instead of two.
Issue 37: Re-format the
COMMON HEADER

The format of the COMMON HEADER seems wierd to
me. The message type is 16 bits and can also hold
flags? Could change this structure



from: [16-bit message type][16-bit flags]
to: [8-bit message type][8-bit message-specific flags][16-bit
generic flags]
May be cleaner, easier to parse, and leaves room for
further enhancement through new flags, in my
humble opinion. Do we really need 16-bits, to allow
for 65535 different messages? We only have 4 now.
Issue 38: Coding of the
standard object header

Coding of the standard object header: why
like this? What are these "r" bits? Sounds
weird that each 16-bit field includes some
unused bits. Could change this



from: [4-bit unused][12-bit type][4-bit
unused][12-bit length]
to: [8-bit type][8-bit reserved][16-bit length]
May be cleaner, and easy to parse (byte, byte,
short). Or, do we need room for more than 256
different object types in QoS NSLP?
Issue 31: Receiving an
unknown TEAR


What happens if the TEAR is set, but no
such state exists? (a possible error
situation, rebooted router, etc.)
What is the behaviour?


Should it silently drop the message?
Or should it assume there is an error
situation somewhere, and it should actually
send the message further?
Issue 32: Last node problem

Last node detection could also be needed, when an
MN has disappeared, and the access router is now
the last QNE for a certain reservation.


So, a node should be able to find out that it has become a
(new) last node on a reservation path, and needs to do
something about it?
Do we need an error messages to say that, and
resulting action is up to the QSPEC.

However, issues appear relating to limiting the scope of any
tear down of old reservations.


Perhaps we need to specify a timeout BEFORE the state is
removed, to allow the possible new branch to be set up.
Is this actually purely a GIMPS issue?
Issue 24: QUERY on upstream
and downstream

A QUERY can be sent downstream and
upstream. How do you send a QUERY
upstream without pre-existing path
state? Does this need a separate error
code to tell that no path state exists for
the specified recipient?
Issue 33: Priority of signaling
messages to GIMPS-NSLP API

There has been discussions on giving
relative priority to certain signaling
messages, e.g., those related to a
handover event. The GIMPS-NSLP API
should provide such a functionality.
Other Things



Hop counting objects
Stacking
Aggregation marking

RAO