NSIS and Mobility Layer Split - PowerPoint PPT Presentation

About This Presentation
Title:

NSIS and Mobility Layer Split

Description:

NSIS and Mobility Layer Split & Framework Issues Robert Hancock NSIS Interim Meeting Columbia University February 2003 Overview Basic Definitions New path ... – PowerPoint PPT presentation

Number of Views:104
Avg rating:3.0/5.0
Slides: 18
Provided by: RobertH100
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: NSIS and Mobility Layer Split


1
NSIS and MobilityLayer Split Framework Issues
  • Robert Hancock
  • NSIS Interim Meeting Columbia University
  • February 2003

2
Overview
  • Basic Definitions
  • New path problems
  • Crossover detection problem
  • Reservation ownership problem
  • CT and CARD

3
Why Bother?
  • Soft-state for all will remove old state and
    install new
  • Imposes yet another criterion for timer setting
  • Or, long periods of poor mid-call operation
  • Alternative explicit messaging
  • How to prevent TEAR message deleting the entire
    path?
  • How to avoid double reservation being rejected
    (spurious resource limitation)

4
Mobility ! Re-Routing
  • Local repair is a simpler problem
  • Includes address-preserving micromobility as a
    special case
  • Re-routing/local repair properties
  • End system addresses not changed
  • Packet classifier update not needed
  • No end to end signalling logically required
  • Reservation theft is hard
  • Depend on weak security of routing network
  • But path characteristics may change

5
Mobility Properties
  • Mobility with ES address changes is harder
  • For NSIS and other protocols
  • NB applies to MIP, HIP, SIP,
  • Different properties
  • E2E packet classifier update needed
  • Other E2E signalling unavoidable (ignoring
    proxies)
  • Harder to prevent reservation theft
  • And, path characteristics may change

6
Path Characteristics Changing
  • In each case for unchanged path part, should
    avoid AAA/policy control
  • Could be the major saving in mobility case
  • Provided ownership can be shown
  • For new part, different rules may apply
  • Different cost/byte, firewall policies
  • Implication signalling application must be
    re-executed along changed part

7
Partial NSLP Execution (I)
  • What we want to do is re-execute NSLP between
    crossover points
  • How does this relate to original e2e NSLP
    execution?
  • NB Implications for NTLP not everything takes
    place in e2e upper layer context
  • How do interior points take charge
  • Does it have to take place in the same
    orientation as the original transaction?
  • Examples????? What assumptions can be made?

8
Partial NSLP Execution (II)
  • Pre-preparation to speed up partial execution
  • Authorise upper bound on resource, not the
    actual amount immediately needed
  • Requires different concept of resource from
    e.g. IntServ
  • Make reservations SE-like (with some constraints)
    rather than FF
  • Cf. old pre-RSVP dynamic filter style
  • Cost of SE compared to FF reservations?
  • Getting back to multicast complexity?

9
Crossover Detection
  • Re-routing case flow-tuple not changed, just
    input/output interfaces (peers)
  • Any additional identifiers needed to correlate
    old and new paths?
  • Mobility case flow-tuple is changed
  • Another identifier needed
  • What else is it used for?
  • What properties does it need?
  • Needs to be e2e unique enough (crossover point
    can be anywhere)

10
Reservation ID
  • NB framework terminology used here
  • A Is this ID used just to detect crossover?
  • And then re-trigger partial NSLP
  • NSLP must have some other reason to believe that
    progressing application with changed flow tuple
    is valid
  • B Or, does simply presenting the ID prove
    ownership in itself?
  • In other words, this is a security issue

11
Reservation ID Security
  • Challenge 1 State the security properties
    required to use ID for (B)
  • NB could be a challenge without general
    authorisation framework for all NSLPs
  • One issue should be considered from both
    endpoints perspectives may need two Ids (!)
  • Challenge 2 Define an identifier mechanism with
    the properties defined in challenge 1.
  • NB not very surprisingly, challenge 2 gets done
    first

12
Reservation ID Mechanisms
  • Three proposals so far
  • Some random combination of address etc
  • Random in perjorative sense
  • No detectable security (or even uniqueness)
    properties
  • Westphal/Chaskar proposal variants
  • Uses counters asymmetric cryptography
  • Very expensive. Other flaws?
  • CASP
  • Make it random and confidentiality protected

13
CT and CARD
  • Background assumptions
  • Framework has ancient text (5.3.5)
  • NSIS protocols MUST still function correctly if
    they dont exist
  • NSIS protocols SHOULD NOT make the seamoby
    performance optimisations useless
  • Anything to say about commonality in signalling
    application space?
  • Should depend on seamoby to solve the general
    edge mobility problem and use their results?

14
CT interactions
  • Two models
  • 1 Handover triggers context transfer which
    triggers signalling application which then uses
    NSIS protocols to initiate session
  • 2 Handover triggers NSIS protocols which use
    context transfer to propagate NSIS state (both
    layers) to new AR and continue session
  • (2) is similar to virtual AR model (Thomas)
  • Implications for NSIS peer relationships
  • Could be an interesting application of SCTP
    multihoming

15
CT Interactions (2)
  • Which model to use?
  • And how to decide?
  • What has to be done to make NSIS protocol state
    context transferable?
  • How to handle the CT/non-CT case
  • Retain seamoby optimisation gt default on
    handover must be no refresh
  • Who generates refresh please if no CT?

16
CARD Interactions
  • Point-point negotiations scope-limited to
    mobile-AR link dont need to involve NSIS
    protocols
  • CARD process also involves query/preparation of
    resources on path from AR back into network
  • So, NSIS protocols are a natural way to deal with
    this

17
CARD Interactions (2)
  • Assumption CARD can invoke NSIS signalling to
    query/prepare resources
  • Consequences
  • 1 Need signalling applications with query as
    well as reserve semantics
  • 2 Success of query involves knowing that new
    request will replace old one
  • I.e. not a double reservation
  • Starts to look like a complete test
    handover/local repair/mobility update procedure
  • Limited to changed path segment
Write a Comment
User Comments (0)
About PowerShow.com