Mobility Discussion (Mobility and Internet Signaling Protocols -00) - PowerPoint PPT Presentation

About This Presentation
Title:

Mobility Discussion (Mobility and Internet Signaling Protocols -00)

Description:

Dead peer discovery mobile node disappears and state is removed because next NTLP hop is gone ... The procedure for finding a dead NSIS peer due to a link or ... – PowerPoint PPT presentation

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

less

Transcript and Presenter's Notes

Title: Mobility Discussion (Mobility and Internet Signaling Protocols -00)


1
Mobility Discussion(Mobility and Internet
Signaling Protocols -00)
  • NSIS Interim Meeting in UK
  • June 3, 2004

2
Goals of This Work
  • This draft is meant as an applicability statement
    and user guide of NTLP/NSLPs in mobile
    environments.
  • We seek to analyse different cases to see whether
    the NSIS protocols could work with basic mobility
  • Making sure there are no initial design mistakes
    that break the protocols in mobile environments
  • Start as analysis, end up as an applicability
    statement showing where the NSIS protocols work
    and where they don't
  • Some cases are not just mobility-specific
  • Stimulating further discussions related to the
    security authorization issues in a mobile
    environment making use of the NSIS protocols

3
Short Problem Statement
  • Change of route and possibly change of MN IP
    address
  • Latency caused by route change due to mobility
  • Explicit routes
  • Path update (Local repair)
  • Upstream local repair vs. Downstream local repair
  • Teardown
  • IP-in-IP encapsulation
  • Peer (MN, CRN, or AR) failures
  • Ping-pong type handover

4
Main Issues Discussed
  • Analysis of various mobility scenarios in NSIS
    signaling
  • Crossover node discovery and Path update caused
    by mobility and route change
  • Dead peer discovery
  • Case examples of NSIS signaling according to
    handover cases
  • Interaction with mobility signaling (e.g.,
    HMIPv6, FMIPv6, CARD, and CTP)
  • Uni- and bi-directional state establishment,
    State Management, and State establishment in
    network mobility and additional issues
  • Security considerations in various scenarios such
    as MN as sender/receiver, multihoming scenarios,
    using context transfer, proxy scenario, and AAA
    interaction

5
Selected Identified Problems
  • Dead peer discovery mobile node disappears and
    state is removed because next NTLP hop is gone
  • Make-before-break handover (or multihoming /
    multiple SCTP associations)
  • Packets with a routing header can take weird
    routes
  • Finding out the cross-over node, how is CRN
    authorized to send messages to repair the state
    on the data path
  • The effect of State management on Path Update
    (e.g., Path Update in stateless QoS model)
  • Others..????

6
Open Issues
  • Selected open issues (?)
  • CRN-related terminologies
  • In the Interworking with HMIPv6,
  • how can the nodes decide locally whether they are
    indeed the UCRN?
  • Can the update of the flow identifier for the
    session be considered only between an MN and an
    MAP to avoid end-to-end signaling?
  • Can the teardown message be sent toward the
    opposite direction of the state initiator?
  • When is the right time to delete the state along
    the obsolete path for fast handover of a
    ping-pong type?
  • How can the crossover node be discovered in the
    specific multicasting/multihoming cases?
  • How does the NAT/FW NSLP affect the CRN discovery?

7
Future Work
  • Restructuring of TOC

Abstract 1. Introduction 2. Terminology 3.
Problem Statement 4. General Considerations 5.
Mobility-Related Issues with NSIS Protocols 5.1
Specific Issues with NTLP 5.2 Specific Issues
with QoS-NSLP 5.3 Specific Issues with NAT/FW
NSLP 5.4 Common issues related to NTLP and NSLP
6. Applicability Statement 6.1 Global- and
local-mobility scenarios 6.2 Failure scenarios
6.3 Use cases of Identifiers
6.4 Backward compatibility 6.5
Aggregation of end-to-end flows in mobility
scenarios 6.6 Multihoming/make-before-break
scenarios 6.7 When CN is mobile 6.8
Bi-directional state establishment in mobility
scenarios 6.9 Refresh interval adjustment in
RANs 6.10 Interactions with mobility-related
protocols 6.11 Guidelines for Implementation of
NTLP and NSLPs 7. Security Considerations
Abstract 1 Introduction
2 Terminology
3
Framework
4 Cross-over Node Discovery and Path
Update 5 Dead Peer Discovery (DPD)
6 Case Examples
6.1 NSIS in the
hard-handover case 6.2 Example
of Signaling of an Anticipated Handoff
7 Multihoming-related
Issues 8
Interactions with Mobility Signaling
9 Additional issues
9.1 Both End-Hosts are Mobile
9.2 Uni- and
Bi-directional State Establishment 9.3 State
Management
9.4 State establishment in Network Mobility
10 Guidelines for Designers of new NSLPs
11 Summary of Split of functionality
12 Security Considerations
12.1 MN as data sender
12.2 CN as data sender
12.3 Multi-homing
Scenarios 12.4 Context
Transfer
12.5 Proxy Scenario
12.6 Implications for the costs of a QoS
resv.
8
Question
  • Do you think this mobility work (Applicability
    statement for mobility support in NSIS protocols)
    would be valuable in NSIS WG?
  • Should this be a WG item, to analyze the
    applicability of NSIS protocol in a mobile
    environment?

9
Backup Slides for further discussion
10
Terminologies (I)
  • Crossover Node (CRN)
  • A Crossover Node is a node that for a given
    function is a merging point of two or more
    separate sets of state information, and not only
    a physical route splitting point. In the context
    of this draft, we can distinguish several logical
    (but not necessarily physically) different CRNs
  • NTLP/NSLP CRN
  • Upstream/Downstream CRN
  • Mobility/Routing CRN
  • Currently, each CRN definition is not obvious, so
    comment on NSIS mailing list.

11
Terminologies (II)
  • Path Update
  • The procedure for the re-establishment of NSIS
    state on the new path, the teardown of NSIS state
    on the old path, and the update of NSIS state on
    the common path due to route change or mobility.
  • Upstream Path Update
  • Path Update for the upstream signaling which is
    initiated by a signaling initiator on the common
    path
  • Downstream Path Update
  • Path Update for downstream signaling which is
    triggered by a signaling initiator on the new
    path (e.g., MN, mobile agent, or an AR).
  • Dead Peer Discovery (DPD)
  • The procedure for finding a dead NSIS peer due to
    a link or node failure and due to a mobile node
    moving away.

12
QoS Signaling in Mobility (II)
  • Resources Reservation in MIP-based access
    Networks
  • How to fast re-establish the resources after
    handover?
  • Path Update
  • How to ferret a Crossover Node?
  • How to delete the obsolete path after handover?
  • Resv message
  • Path message
  • Teardown message
  • RSVP session

CRN
AR
NAR
AR1
AR
13
Crossover Node Discovery
  • Discovery
  • Issue I
  • If the merging point is NOT NSIS-aware and can
    NOT act as a crossover node?
  • Session_ID, flow_ID, Incoming interface, and
    Mobility Object.

Flow ID
MO
interface
Session ID
interface
Switching Fabric
Session ID
Switching Fabric
(1)
CRN
AR2
AR1
14
CRN discovery (contd) Route Change vs.
Mobility (I)
  • Approaches
  • Coupled approach
  • Separated approach
  • At the NSLP level,
  • CRN is determined by comparing the Source
    Identification Information (SII) contained in the
    incoming signaling message to that of previously
    stored in the node.
  • At the NTLP level,
  • CRN discovery can be considered as an extension
    to the peer discovery
  • (e.g., using GIMPS query-response)
  • Mobility
  • may cause the change of the flow identifier.
  • the flow identifier should be updated along the
    entire chain of NSIS entities
  • A For each flow, a CRN is only discovered
  • Upstream CRN (UCRN) / Downstream CRN (DCRN)

15
CRN discovery (contd) Route Change vs.
Mobility (II)
  • Route Change
  • the flow identifier does NOT change after the
    standard route change
  • If an unique Session ID is used
  • For each (upstream/downstream) flow,
  • the route change results in forming a chain of
    divergence and convergence CRN pair in the
    network.
  • Diverging CRN and Converging CRN
  • The existing RSVP Session
  • New RSVP session

Diverging CRN
Converging CRN
16
Path Update
  • Localized QoS signaling
  • Upstream Path Update
  • for the upstream signaling, it is initiated by a
    signaling initiator on the common path (e.g., a
    CN, a HA, or a GFA/MAP).
  • Downstream Path Update
  • for downstream signaling, it is triggered by a
    signaling initiator on the new path (e.g., MN,
    mobile agent, or an AR)

CN
CN
DCRN
UCRN
2
1
3
3
2
NAR
NAR
OAR
OAR
1
Sender
Receiver
17
Path Update (contd)
  • Open issues
  • In the Interworking with HMIPv6,
  • how can the nodes decide locally whether they are
    indeed the UCRN?
  • Can the update of the flow identifier for the
    session be considered only between an MN and an
    MAP to avoid end-to-end signaling?
  • Can the teardown message be sent toward the
    opposite direction of the state initiator?
  • When is the right time to delete the state along
    the obsolete path for fast handover of a
    ping-pong type?
  • How can the crossover node be discovered in the
    specific multicasting/multihoming cases?
  • How does the NAT/FW NSLP affect the CRN discovery?

18
State Management
  • Soft state
  • It may be necessary to set the refresh timer
    value in a wireless network to a smaller value
    than that in the core (wired) network
  • by manual configuration
  • by some adaptive technique
  • Use of Refresh bit to efficiently
  • reserve resources
  • PRE bit for preservation
  • M bit for Mobility session

19
State Management
  • Soft state
  • It may be necessary to set the refresh timer
    value in a wireless network to a smaller value
    than that in the core (wired) network
  • by manual configuration
  • by some adaptive technique (Our proposal)
  • Use of Refresh bit to efficiently reserve
    resources
  • PRE bit for preservation
  • M bit for Mobility session

20
State establishment in NEMO
  • Aggregate reservation
  • The solutions in the NEMO WG will support
    preservation of route aggregation in the network
    when flows of MNs (and/or fixed hosts) in a
    mobile network are sent to the same HA or CN.
  • Issue
  • Pinball routing problem
  • the nested mobile networks cause this issue
    because flows of each mobile network may transit
    multiple HAs through multiple bi-directional
    tunneling.
  • Multihoming-related issue

21
Reservation Mode
  • Sender-Initiated
  • the MN (as a sender) can initiate a reservation
    setup for its outgoing flows as soon as it has
    moved toward another AR.
  • Receiver-Initiated
  • MN (as a sender) somehow has to inform the
    receiver of its handover
  • Delayed signaling problem occurs
  • Bi-directional reservation
  • The bidirectional data flows have the same end
    points, but the path in the two directions does
    not need to be the same.
  • a crossover node for downstream reservation may
    be different from that for upstream reservation

22
Mobility Event detection
  • Mobility Object
  • To prepare immediate handover
  • i.e., for fast QoS re-establishment
  • When an MN detects a handover (e.g., by layer 2
    trigger),
  • NSLP of the MN may set the MOBILITY object in
    the refresh message and sends it to the current
    AR (1).
  • NSLP of the AR after receiving the movement
    information (2).

23
Interaction with Mobility Protocols
  • During handover
  • Movement Detection
  • e.g., RtSolPr message in Fast Handover for
    MIPv6
  • CARD CT
  • To fast re-establishment or pre-establishment
  • After handover
  • NTLP/NSLP messages should be simultaneously sent
    with handover information
  • BU message in MIP

24
Dead Peer Discovery (DPD) Overview
  • A dead peer can occur
  • A link or a network node, including the MN and
    CRN, failed, or
  • The mobile node moved away without informing
    NSLP/NTLP
  • The procedures for handling DPD should be the
    same no matter why a peer is dead
  • because an NE discovering a dead peer cannot
    judge the specific reason
  • DPD due to a link or node failure, and DPD due to
    an MN moving away should trigger the same
    reaction

25
Dead Peer Discovery (DPD) Overview (contd)
  • Dead peers should be discovered as soon as
    possible to minimize service interruption
  • NSIS needs to find a different path
  • NSIS state needs to be set up along the new path,
    and NSIS state needs to be torn down along the
    old path
  • Care must be taken to terminate teardown at the
    CRN since the NSIS state on the common path
    should not be deleted

26
DPD Failure Cases
  • Dead peers of interest in mobility scenarios
  • CRN, MN, and AR
  • Only NSIS functions (i.e., NTLP/NSLP) of the node
    may fail, or the physical hardware
  • An MN may either fail or move

27
DPD Impact of Dead Peers
  • The failure of an NSIS CRN
  • A new CRN should be discovered immediately
  • The failure or movement of an MN may cause the
    'invalid NR' problem
  • The failure of an AR may make the interactions
    with Seamoby protocols (such as CARD and CT)
    impossible.
  • In this case, the neighboring peer closest to the
    dead AR may need to interact with CARD and CT
Write a Comment
User Comments (0)
About PowerShow.com