1 / 14

NSIS Diagnostics Design Options

This document discusses various design options for NSIS diagnostics, including the problem, operators/sysadms' needs, and different proposals for diagnosing GIST and NSLP information.

zacharias
Download Presentation

NSIS Diagnostics Design Options

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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!

More Related