Transcript PPT Version

Mobility Discussion
(Mobility and Internet Signaling Protocols -00)
NSIS Interim Meeting in UK
June 3, 2004
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
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
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
Future Work
• Restructuring of TOC
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.
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
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?
Backup Slides for further
discussion
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.
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.
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
CRN
• Teardown message
3
AR
NAR
1
AR1
AR
2
• RSVP session
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.
MO
Flow ID
interface
Session ID
interface
Switching
Fabric
Session ID
(1)
Switching
Fabric
CRN
AR1
AR2
CRN discovery (cont’d)
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)
CRN discovery (cont’d)
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
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
DCRN
CN
UCRN
2
1
3
3
2
OAR
NAR
1
Sender
OAR
NAR
Receiver
Path Update (cont’d)
• 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 endto-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?
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
1 Setting the timer (M bit)
– by some adaptive technique
• Use of Refresh bit to efficiently
•
reserve resources
• ‘PRE’ bit for preservation
• ‘M’ bit for Mobility session
P M
Ver flag
type
checksum
TTL
reserved
Length
Length
5
1
Refresh period R
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
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
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
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).
Candidate CR
AR4
(2)
(2)
AR3
AR1
(1)
AR2
candidate
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
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
Dead Peer Discovery (DPD):
Overview (cont’d)
• 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
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
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