Design Options of NSIS Diagnostics NSLP <draft-fu-nsis-diagnostics-nslp-01.txt>

1
Design Options of NSIS Diagnostics
NSLPltdraft-fu-nsis-diagnostics-nslp-01.txtgt

• Xiaoming Fu
• Ingo Juchem
• Christian Dickmann
• Hannes Tschofenig

2
Acknowledgment

• Thank following colleagues for discussions of
  various issues in the list and/or individually
• Bob Braden
• Scott Bradner
• Elwyn Davies
• Allison Mankin
• Jukka Manner
• David Oran
• Martin Stiemerling
• Sebastian Willert
• (and some other members in NSIS WG)

3
Problem Statement (1/2)

• Operators/sysadms may want to have a means to
  diagnose the NSIS nodes for their own domains
• for detecting NSIS/NSLP support in these nodes
• for detecting NSIS states in these nodes
• Possibly, an NSIS end user may want to diagnose
  the network NSIS information, too (security?)
• Users QoS reservation information?
• Firewall/NAT existence?
• RFC2475 per session PATH/RESV state diagnostics

4
Problem Statement (2/2)

• Currently, GIST does not support any multi-hop
  diagnostics functions
• Stack proposal negotiation only takes place
  between peers
• QoS NSLP
• Query messages are used for determine the
  available resource information
• No QOSM ID discovery
• NAT/FW NSLP
• Latest version defines a Trace to identify
  NATFW nodes
• ?A generic diagnostics NSLP might be needed

5
Next Steps

• Is this work useful?
• Next steps with diagnostics functions?
• Inputs, comments and suggestions appreciated!

6
Appendix
7
Design Options (1)

• Issue which GIST information should be diagnosed
• Option 1 MAs in each GIST node
• Pro helpful to diagnose the current available
  MAs
• Cons implementation-specific?
• Possible presence every MA table in the GIST
  node
• Option 2 all MRSs in each GIST node
• Pro get info on every active NSIS sessions in
  each node
• Cons too fine granularity? Large message size?
  Authorization issues?
• Possible presence the number of MRSs along the
  path or detailed MRSs but limit to a domain
• Open issue who can query GIST info? NI/NR or any
  NE?
• Proposal sysadmin and limit to his domain only,
  very limited information given to end user within
  same domain after authorization

8
Design Options (2)

• Issue Which NSLP information should be
  diagnosed?
• Option 1 supported NSLP-IDs in each GIST node
• Pro simple
• Cons not useful enough?
• Recall GIST only talks to the next node
  supporting the requested NSLP
• Possible presence take it, but add a bit more
  info
• Whether is a FW or NAT, QOSM-ID info etc.
• Option 2 aggregated NSLP state information in
  each GIST node
• Pro may be useful
• Cons how? Authorization issue?
• Option 3 all detailed individual NSLP state
  information
• Pros Authorization issue message too large?
• Open issue authorization issue who can issue
  the query?
• Proposal Only sysadm to query Option 2, Option 1
  handled less strictly

9
Design Options (2b)

• Issue Granularity of NSLP state?
• Option 1 a sysadm to query all NSLP session
  state?
• Pro all info for diagnosing NSLP status
• Con too fine-grained? MTU issue?
• Proposal a summary of NSLP session state(?) (How
  exactly?)
• Option 2 a NI/NR to query its NSLP session
  state?
• Pro authorization issue seems to be easier
• Con what about triggered by other entities?
• Option 3 a 3-part to query an established NSLP
  session state (RSVP fashion)
• Pro flexible
• Con requires policy definition/proper
  authorization model

10
Design Options (3)

• Issue Which message sequences of the diagnostics
  func
• Option 1 query being delivered to each GIST node
  along the path, response directly back to the
  querying node
• Pro simple
• Con anything required to be added in the reverse
  direction?
• Option 2 both query and response being processed
  hop-by-hop fashion
• Pro gather everything potentially needed, eg,
  timestamps in GIMPS ping
• Con more complex, require larger size which has
  to be adressed

11
Design Options (4)

• Issue Does diagnostics create any NSIS state?
• Option 1 No (i.e., just use GIST stateless
  delivery)
• Option 2 GIST state only
• Pro can be used to collect reverse direction
  info if required
• Con maybe prone to DoS attacks
• Proposal No any state should be introduced (if
  no reverse direction info is required)

12
Design Options (5)

• Issue Encapsulation of the message
• Option 1 D-mode (UDP).
• Pro does not need to introduce any state
• Con MTU limitation
• Option 2 C-mode (e.g. TCP)
• Pro reuse existing MAs does not hurt, No MTU
  issue
• Con when no MA between two peers, needs to
  introduce MAs
• Does one want to remove it? If so reverse routing
  is needed
• Proposal
• Use MRM object for query msg routing
• D-mode as default, when MA exists, reuse it.

13
Design Options (6)

• Issue Message formatting
• Option 1 All TLV Objects for each info
• Pro generic presentation
• Con more bits required
• Option 2 compacted into a message segment for
  info gathered in each node
• Pro smaller size
• Con any changes difficult later
• Proposal Option 1

14
Strawman Design Towards a Diagnostics NSLP

• DIAGNOSTIC-message Common header, Query
  object, Hop object
• Common header Diag_NSLPID, type (query or
  response), total length
• Query header which info needs to be queried
• Hop-object Hop header IP address object
  General GIST information object SID-bound
  Response object NSLP state information object
  Available NSLPs object Additional information
  object