NSIS%20Framework%20Issues%20draft-ietf-nsis-fw-02.txt

1
NSIS Framework Issuesdraft-ietf-nsis-fw-02.txt

• Robert Hancock (ed.), Ilya Freytsis, Georgios
  Karagiannis, John Loughney, Sven van den Bosch
• IETF56 San Francisco
• March 2003

2
Overview

• Status
• The five open technical points
• What happens next

3
Current Status Technical

• draft-ietf-nsis-fw-02.txt (now)
• Major update and restructuring since 01 version
• Technical points to note
• Layer split decisions have made NTLP thinner
• Sender/receiver aspects, resource management,
  authorisation aspects shifted upwards
• NTLP is single-hop-scope (with careful
  definition)
• Addressing mode and any internal NTLP layering
  are design decisions
• Minimal flow id (not full packet classifier) is
  in
• Based on outer headers only (e.g. CoA not HA for
  MIP)
• Limited ambitions for session identification

4
Current Status Editorial

• Re-arrangement of sections and content around 2
  layer model
• First sections about layer boundary and NTLP
  properties
• Includes section on how we go beyond the RSVP
  problem space (types of NSLP flexibility)
• Final section on QoS signalling as worked
  example
• Terminology fixes flow-id, NTLP?
• Maybe it reads better, maybe it doesnt
• Easiest to read it again

5
Issue 1 Transport

• Traditional transport-layer like behaviour
• Congestion avoidance flow control
• Reliability aspects (e.g. achieving rare message
  loss)
• Bundling Segmentation
• Possible consensus position?
• None can permanently be ruled out as un-useful
• The NTLP (or, below NSLP) is the right place for
  them
• Some signalling applications/environments wont
  need to invoke that protocol support
• They dont need the function or it comes for free
  somehow
• They can save the cost

6
Issue 1 Way Forward

• Framework should say crudely how this issue is
  managed
• In general flexible support below NSLP
• Right way to manage optionality depends on the
  function who it affects, who benefits
• Example (not a proposal!!!!!!!)
• Bundling NTLP can do it if it likes to
• Low loss likelihood signalling application can
  demand, NTLP can decide how to provide it
• Congestion control NTLP can protect local
  network, but note this doesnt replace e2e
  protection
• Conclude on list in near future?

7
Issue 2 Big Picture Aspects

• A main change from RSVP?NSIS is multi
  application support
• Discussion is still a bit QoS oriented
• Dont know how much multi-application support
  should be thought about
• Periodically, points raised about the
  even-cleverer-things that could be done
• More complex routing interactions (automatic
  traffic engineering and so on)
• More complex charging/authorisation models
• Text welcome, wont hold up document for it

8
Issue 2a QoS NSLP

• Current framework gives very high level view of
  what QoS NSLP could do and how it could fit in to
  rest of network
• Not many concrete statements about exactly what
  the protocol should do
• Replicate RFC2205? More? Less?
• State this in the framework?
• Prefer leave it open - keep framework focussed
  mainly on NTLP and overall structure

9
Issue 3 Mobility

• Picture of signalling in context of
  macro-mobility and fast handover protocols is
  missing
• Impacts what optimisations are really useful
• Expectation NTLP role is limited to detecting
  route changes for flows and sessions
• Then triggering NSLP do something about this
• NTLP knows about session identification, but
  doesnt guarantee any security-related properties
• I.e. session ownership problem is for
  signalling application to worry about (its hard
  non-local)
• Probably, more pictures discussion needed

10
Issue 4 One or Many Hops

• Are NSLP peers joined by a single NTLP hop?
• Or, might the link between like NSLPs run over
  more than one hop concatenated together?
• Current assumption 2nd case cant be avoided
• Implications currently unclear
• See if protocol designers can make problem go
  away
• If they want to

11
Issue 5 State Management

• Should the NTLP do state management for
  signalling applications?
• What does this mean if anything for the
  protocol?
• Should it provide a service to NSLPs to create
  and manage opaque state blobs for them? Or
• Should the NTLP be used just to get opaque data
  to between NSLP peers?

12
State Management (part II)

• Different NSLPs have different qualitative state
  management requirements/semantics.
• E.g. soft state (explicit or implicit refresh),
  timeout deletion or just maybe not kept, even
  hard state
• Different quantitative aspects
• E.g. Lifetimes, lifetime precision, refresh
  criticality
• What would integration with the NTLP buy you?
• Putting state management functions in NTLP makes
  the NTLP API much more complex
• If NSLP peers arent always NTLP peers then even
  harder to define and analyse

13
State Management (part III)

• But RSVP uses fact that messages are just
  refreshes in order to do scheduling tricks
• These tricks would need to be in NTLP (probably)
• Maybe refresh messages generated in NTLP, maybe
  it just knows how to identify them
• Could be just an API issue
• Impact NTLP has 2 message types refresh
  non-refresh (for create, notify, tear)
• Maybe proposal limit to this
• (but needs more analysis)

14
What Next

• 0 Continue editorial fixing
• Send your comments now!
• 1 Agree on transport issues
• 2 Accept text on big picture issues
• 3 Refine mobility description
• 4 Refine multi-hop analysis (maybe)
• 5 Discuss and agree on requirements for state
  management
• Next version early May (maybe)