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

1. Design Options of NSIS Diagnostics NSLP<draft-fu-nsis-diagnostics-nslp-01.txt> 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?) • User’s 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]