1 / 7

Robert Hancock, Eleanor Hepworth, Andrew McDonald IETF #55 - Atlanta November 2002

NSIS Sender-Receiver Issues draft-hancock-nsis-sender-receiver-00.txt (This is a disposable draft to progress a specific framework issue.). Robert Hancock, Eleanor Hepworth, Andrew McDonald IETF #55 - Atlanta November 2002. The Problem.

mgay
Download Presentation

Robert Hancock, Eleanor Hepworth, Andrew McDonald IETF #55 - Atlanta November 2002

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. NSIS Sender-Receiver Issuesdraft-hancock-nsis-sender-receiver-00.txt(This is a disposable draft to progress a specific framework issue.) Robert Hancock, Eleanor Hepworth,Andrew McDonald IETF #55 - Atlanta November 2002

  2. The Problem • Directionality has implications for how the protocols operate • Implications are layer (NTLP/NSLP) related • Not clear how to proceed • Conflict between simplicity and flexibility desires • Difficult to proceed elsewhere without working assumptions

  3. What’s Needed (?) • Some NSLPs and some user applications may fit better to one approach • Latency, negotiation issue • NATs may also limit who knows addresses • Renegotiation may be wanted both ways • Also a consequence of signalling localisation • Authorisation might be easier from sender • State management issue • May want to find out about ‘far end’ issues

  4. What’s Constrained • NTLP basically must work senderreceiver • May or may not need to store  state • Additional work at intermediate nodes • Depends on NSLP requirements • Interworking (e.g. with RSVP) may impose constraints on operation • Future multicast support might require receiver initiation (at some layer)

  5. Options • 1: Fix one paradigm • Simple, lightweight – probably rules out some requirements and deployment scenarios • 2: Allow everything you can think of • Excessive freedom and complexity • 3: Tune the support in each layer independently

  6. Layering Proposal • NTLP operates in sender-oriented mode • Sets ‘signalling directionality’ for upper layer • Default allows up- and downstream signalling • Optimisation: downstream only • NSLP is sender or receiver oriented depending on the application and scenario • NI/NF/NR and message types must be NSLP layer concepts • State management implications TBD (!)

  7. Other Stuff • ‘Integrated’ bidirectional operation (exploiting symmetric paths) • NTLP instances operate independently • Local API could present bidirectional interface? • Path-decoupled handling • If you believe NTLP handles path construction • Then need new path-decoupled NTLP • Once the NTLP has defined orientation, NSLPs can be unchanged?

More Related