QoS%20NSLP%20Open%20Issues

1
QoS NSLP Open Issues
2
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?

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

4
Issue 27 Filters

• Where and how are filters given?
• To identify the flow(s) that should receive a
  certain QoS.

5
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

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

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

8
Issue 28 Different QUERY messages

• How to distinguish a generic QUERY from one
  intended to trigger a receiver-initiated
  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.

9
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.

10
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 QoS-NSLP 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.

11
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 type16-bit flags
• to 8-bit message type8-bit message-specific
  flags16-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.

12
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 unused12-bit type4-bit
  unused12-bit length
• to 8-bit type8-bit reserved16-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?

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

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

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

16
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.

17
Other Things

• Hop counting objects
• Stacking
• Aggregation marking
• RAO