1 / 14

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

Design Options of NSIS Diagnostics NSLP <draft-fu-nsis-diagnostics-nslp-01.txt>. Xiaoming Fu Ingo Juchem Christian Dickmann Hannes Tschofenig. Acknowledgment. Thank following colleagues for discussions of various issues in the list and/or individually: Bob Braden Scott Bradner

osmond
Download Presentation

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

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

More Related