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

1. Design Options of NSIS Diagnostics NSLP<draft-fu-nsis-diagnostics-nslp-00.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. Overview • Problem • Design options • Next steps

4. Problem • Operators/sysadms may want to have a means to diagnose the NSIS nodes • for detecting NSIS support in these nodes • for detecting NSIS states in these nodes • At least for their own domains • An NSIS end user may want to diagnose the network NSIS information, too (?) • User’s QoS reservation information? • Firewall/NAT existence? • RFC2475: per session PATH/RESV state diagnostics

5. Problem (Cont.) • 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 • QOSM ID support information is not clear at the moment • NAT/FW NSLP • Latest version defines a “Trace” to identify NATFW nodes A generic diagnostics NSLP might be needed

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

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

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

9. 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 • Proposal: Option 1

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

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

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

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

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