Applicability Statement of NSIS Protocols in Mobile Environments

(draft-ietf-nsis-applicability-mobility-signaling-01)

Sung-Hyuck Lee, Seong-Ho Jeong, Hannes Tschofenig, Xiaoming Fu, Jukka Manner

NSIS Interim Meeting in Munich, GermanyMar. 8, 2005

Outline• Current Status

– Identified Issues– Duplicated issues addressed in QoS-NSLP and NSIS mobility drafts

• Main issues– CRN-discovery issues – Interfaces between mobility management and NSIS protocols – Invalid NSIS Responder Problem – Authorization-related issues with teardown– Optimal refresh timer value for mobile environments – CRN discovery and Path Update on the IP-tunneling Path – Priority of signaling messages – Localized Path Update– Other possible issues

• Next Steps

Current Status

• Issues identified: overview– Crossover node (CRN) discovery-related issue– Interfaces between mobility management and NSIS protocols– Invalid NSIS Responder (NR) Problem– Optimal refresh timer value for mobile environments– CRN discovery and Path Update on the IP-tunneling Path

– Localized Path Update– Multihoming-related issues– Priority of signaling messages (of MN rather than that of fixed

hosts)– Update of firewall rules and NAT bindings – Re-use of NAT/FW-NSLP's old state– Security issues

Addressed

Not-addressed

Duplicated issues addressed in NSIS WG-IDs

• Some issues addressed through the QoS-NSLP issue list– Make-before-break handovers (including Seamoby-related issues)

• Addressed at the initial NSIS mobility draft, but removed by Allison’s comments

– Last node problem• Similar to the “Invalid NR problem”

– Explicit indication of refresh & priority-related issues • Related to the “priority of signaling messages”

– Node failure and restart handling• “Dead peer discovery”

– etc.

Open Issue #1: CRN-discovery issues (I)

• Question: – Which layer should be responsible for the NSLP CRN discovery,

NTLP (GIMPS) or NSLP (e.g., QoS-NSLP and NAT/FW-NSLP)?

• Description: – The NSLP CRN can be discovered at the GIMPS during the

procedures of the peer discovery and the messaging association• Although the QoS-NSLP can detect the change of signaling path and

discover the NSLP CRN by keeping track of SII – Processing overheads (NTLP vs. NSLP) and the functions of the

identifiers in NTLP and NSLP.

Open issue # 1: CRN-discovery issues (II)

• Procedure of Messaging AssociationGIMPS-Query

MRI/SID/NSLPIDResponding

NodeQuerying

Node

Q-Node Network Layer InfoQuery Cookie

Q-Node Stack-Config Data][Q-Node Stack-proposal

Router Alert Option

GIMPS-Response

[NSLP payload]

MRI/SID/NSLPIDR-Node Network Layer Info

Query Cookie

R-Node Stack-Config Data][R-Node Stack-proposal

[NSLP payload]

GIMPS-Confirm

[Responder Cookie]

Open issue #1: CRN-discovery issues (III)

AR1 AR2

Physical merging point

NSLP-CRN

Switching Fabric

NSLP_Br_ID = Logical interfaces

Session ID

Switching Fabric

Physical interface

Flow IDMO- Whether the same

NSLP_ID exists- Whether the corresponding CRN has been discovered- Whether the same SID and MRI exist- Whether the NSP_Br_ID has changed- Optionally, the Mobility identifier can be examined

Need to check:

Open issue#1: CRN-discovery issues (IV)

• Possible options:– (a) the NTLP should discover NSLP CRN where the routes of flows are

merged, and report this to the NSLP– (b) the NSLP should decide whether it is a CRN which has to do Path

Update (i.e., local repair)

• Preference (a) – (a) may decrease the complexity of overall NSIS protocol processing,– Considering other signaling applications including NAT/FW-NSLP, the

operation may be simpler with (a).

• Preference (b)– (b) requires additional messages at the NSLP level, but this may be

required anyway for reporting route changes which are discovered directly by signaling applications.

Open issue #2: Interfaces between mobility management and NSIS protocols (I)

• Question: – Is it necessary to define a Mobile IP-specific API in NSIS, or a

common triggering mechanism between routing and NSIS processes to monitor the operations of other mobility protocols?

• Description: – NSIS protocols may need to monitor the procedure of Mobile IP

and then to react to the mobility events to continually support the existing NSIS state after handover,

– That is, an NSIS implementation needs to be developed to react based on the endpoint notification.

Open issue #2: Interfaces between mobility management and NSIS protocols (II)

• Additional questions rise…– Which information of the mobility management protocols should

be monitored? – How and what information can the NSLP expect from NTLP, or

directly from the routing interface after a mobility event happens?– How is the binding update interval coordinated with the NSIS

signaling interval?

Open issue #2: Interfaces between mobility management and NSIS protocols (III)

• Suggestion and related questions– List some triggers from NTLP and Mobile IP– Analyze the sorts of events from Mobile IP

• What does the event mean?• Where is the event detected?• What bit of NSIS the event could usefully be delivered to locally

– Questions • Are some mobility events visible to the NTLP when a Mobile IP hand

over (new CoA) would just pop up as a new flow?• Can NTLP know about relationship b/w old and new CoAs?• If not, is NSLP interested in caring about the relationship?

Open issue #3: Invalid NSIS Responder Problem (I)

• Question: – How/by whom can RESPONSE (or Refresh) message be sent to

the corresponding QNI if QNR (e.g., an MN) performs handover before the receipt of the message?

• Description: – If the old AR is the last node on the old path due to the MN's

handover, its QoS-NSLP may trigger an error message to indicate that QoS-NSLP messages (e.g., RESERVE) cannot be forwarded any further.

– In this case, an error message should not be sent to avoid any teardown on the old path before re-establishing the state along the new path (make-before-break handover).

Open issue #3: Invalid NSIS Responder Problem (II)

OARNAR

CRNCN

Refresh

OAR NAR CRN CNMN

Refresh

Error message

Teardown

HO

Open issue #3: Invalid NSIS Responder Problem (II)

• Suggestion to protocols: – May use handover_init (HI) field of the Mobility object to inform

the current AR of a handover.– In this case, there may be some approaches to solve the Invalid NR

problem• The current AR may be a proxy for the MN (the last node) and it may

be able to send RESPONSE messages in response to REFRESH (or RESERVE) messages.

• The current AR may forward the NOTIFY message including the HI field toward CN to prevent the NI from removing the NSIS state.

– Identification of the last node in mobility scenarios

Open issue #4: Authorization-related issues with teardown (Closed?)

• Question: – Can the teardown message be sent toward the opposite direction to the state

initiating node when tearing down the obsolete state after CRN discovery?

• Description: – This leads to an authorization problem because a node which does not initiate

signaling for establishing the QoS-NSLP state may delete the state.

• Suggestion: – Disabling of “reverse removal”: Only a state installer can perform teardown.

• The session/reservation ownership problem (draft-tschofenig-nsis-sid-00.txt).»

• Additional question,– Is it necessary to use the tear-down message to release the old state?

• The old state will time out by using soft state as the general approach.

Open issue #5: Optimal refresh timer value for mobile environments 

• Question: – How should the refresh timer value be set up according to various

mobility scenarios?

• Description: – In the frequent handover scenarios, the maintenance of state on the

old path for a long time is not necessary.  – The QoS-NSLP needs to choose appropriate refresh intervals

depending on the network environment (e.g., access network, or core network) to reduce the waste of resources. 

• In the case where the soft state approach is preferred to any explicit tear-down approach in order to release the old state in mobility scenarios (#4)

Open issue #6: CRN discovery and Path Update on the IP-tunneling Path

• Question: – How can NSIS discover the CRN and perform Path Update on the tunneling

path?

• Details: – When IP-tunneling is used in the MIP-based network, it is also needed to

perform the path update on the tunneling path. • If the CRN is located on the tunneling path, how can the CRN be discovered for

the path update? • When/how to re-setup the state and remove the old state on the tunneling path? • If route optimization is used after IP-tunneling, when should the state on the

tunneling path be removed?

• Comments from ML– The operation on the tunneling path can be related to flow ID management.– Do the issues need to be more clarified in this draft or a separate draft?

Open issue #7: Priority of signaling messages

• Question: – Should a high priority be given to the signaling message to

expedite signaling process?

• Description: – Some messages of QoS-NSLP need to be used to check the

availability of resources in a new access network to ensure that the moving MN get the required QoS. For example, the QUERY message can be used for that purpose.

• Additional question:– Does a high priority need to be given to signaling messages of MN

rather than that of fixed hosts?

Open issue #8: Localized Path Update (I)

• Question: – Do we need to consider some micro-mobility management protocols to

localize NSIS signaling after mobility event?

• Description: – One of major issues on QoS signaling in mobility is end-to-end signaling

problem because it causes QoS degradation by undesired delay. – The Path Update needs to be localized to enhance performance parameters

such as signaling setup delay, resource utilization, and so on.– A possible approach: the interaction b/w the micro-mobility management

protocols (e.g., HMIP, FMIP, etc.) and NTLP protocols. – For example, when interacting with HMIP, how is the Path Update

performed with scoped signaling messages within the access network under the control of MAP?

– Rising Question: Does micro-mobility management protocols need to be considered in the NSIS mobility draft?

Open issue #8: Localized Path Update (II)

OARNAR

DCRN

Sender

CN

OARNAR

UCRN

3

Receiver

CN

1

3

2

1

2

Downstream Path Update

Upstream Path Update

Other potential issues

• Update of firewall rules and NAT bindings (closed?)• Re-use of NAT/FW-NSLP's old state (closed?)• Security issues

– Key exchanges– AAA-related issues

Next steps

• Identify and clarify the following issues– Multihoming-related issues– The security-related issues – The QSPEC-related issues – Performance constraints (e.g., scarce bandwidth on wireless link)

• Describe interaction between NSIS protocol suite and mobility protocols (in detail)

• If open issues and problems are detected give guidance to protocol authors (before protocols are frozen)

Implementation Experience on NSIS Mobility

NSIS mobility implementation

• NTLP/QoS-NSLP prototype– Redhat Linux 9.0 – Kernel version 2.4.x– IPv6 only (But, some codes are available in both IPv4 and IPv6)– Based on draft-ietf-nsis-ntlp-04.txt– Based on draft-ietf-nsis-qos-nslp-03.txt

• Mobile IPv6 prototype– Source code: sait-mipv6-2.4.22– Based on draft-ietf-mip6-mobileip-24.txt

• Some applications– Streaming server: VLC– Background traffic: Mgen– Measurement tool: TTT

Structure of MIPv6 Testbed

MN

PAR

MN

NAR

Core RouterCRN NR-1

HA

CNeth1 – 3ffe:2e01:1:5::1/64eth0 – 3ffe:2e00:e:a::2/64

eth0 – 3ffe:2e01:1:6::1/64eth1 – 3ffe:2e00:e:b::2/64

eth1 – 3ffe:2e00:c:b::1/64eth0 – 3ffe:2e00:c:a::1/64

eth1 – 3ffe:2e01:1:7::1/64

eth0 – 3ffe:2e00:e:c::1/64eth1 – 3ffe:2e00:c:b::2/64

eth1 – 3ffe:2e00:e:c::2/64

eth3 – 3ffe:2e00:c:a::2/64

eth1 – 3ffe:2e00:e:a::1/64eth2 – 3ffe:2e00:e:b::1/64

eth0 – 3ffe:2e01:1:5:…… eth0 – 3ffe:2e01:1:6:……

eth1 – 3ffe:2e01:1:7::1/64

Testbed Scenarios

MN

AR 1 AR 2

CRN

AP 1 AP 2

HA

TTT

CNIPv6

IPv6

Hub Core Network

Over-subscribed Network

Under-subscribed Network

(Streaming server)

IPv6

Thank you for your attention!

Please give comments on the NSIS mailing list.