Applicability Statement of NSIS Protocols in Mobile Environments

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

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

The 63rd IETF meeting in Paris, France Aug. 4, 2005

NSIS-mobility Issue Tracker

• Issue tracker can be found at http://www.tschofenig.com:8080/nsismob

• Please visit there and put on some texts on it.

Status of –02 version (I)• Issues closed based on discussions at the Munich interim meeting.

– #4: Authorization-related issues with teardown• solved by disabling of “reverse removal”

– #7: Priority of signaling messages• Can not be used by security issues

• Remaining issues to be resolved:– #1: CRN discovery

• the pros and cons of two discovery mechanisms on CRN was described in more details: either at NTLP layer or NSLP layer.

– #2: Mobile IP specific API • This issue is a little implementation-specific, but the usage of an API needs to

be described.– #3: Invalid NSIS Responder problem

• Some possible proposals to solve the 'invalid NR' problem in mobility scenarios was described (e.g., Mobility Object: handover_init (HI)).

Status of –02 version (II)• Remaining issues to be resolved (cont.):

– #5: Optimal refresh timer value for mobile environment• Difficult to provide generic mechanism.• Provide detailed values (for specific scenarios)

– #6: CRN discovery and Path Update on the IP-tunneling path • Described possible issues in NSIS-mobility draft• Suggest solutions in separate drafts

– #8: Localized Path Update• Identify the difference b/w the local mobility and micro mobility

management protocols in case of interaction with NSIS protocols• Consider signaling optimization in the vertical handover scenarios.

– #9, #10, #11, and #12: newly found

Status of –02 version (III)• Some overlapped issues between QoS-NSLP and NSIS-mo

bility drafts– #29: Make-before-break handovers (including Seamoby-related iss

ues)• Addressed at the initial NSIS-mobility draft

– #32: Last node problem • Similar to the “Invalid NR problem (#3)”

– #33: Priority of signaling messages to GIMPS-NSLP API & #39 Explicit indication of refresh

• Related to the “priority of signaling messages (#7)”– #17: Node failure and restart handling

• “Dead peer discovery (#9)”

• How should we resolve the conflict? • Who describes what?

Open issue #9: Dead Peer Discovery

• Issues: – Dead peers (e.g., AR (or FA), CRN, HA or MN ) can occur either

because a link or a network node failed, or MN moved away without informing NTLP/NSLP (e.g., QoS- or NAT/FW-NSLP).

– GIMPS discovery will detect the problem after some time: it says that GIMPS discovery might be slow (?).

• Question: – How can dead peers be detected in a fast and efficient manner in m

obility scenarios? GIMPS discovery?– Do some “dead peer” cases need to be identified?

• e.g., MN’ moving-away, CRN failure, CARs’ failure, FA/HA’s failure, and so on.

Open issue #10 Multihoming issues

• Issues: – An NSIS-aware node (e.g., MN, HA, CN, etc.) may be multihomed. NSIS

signaling can be used in such multihomed environments. – In this case, which NxLP functionality is needed in various multihoming s

cenarios (e.g., bandwidth increase, load balancing, bi-casting, resilience, etc.) is an open question.

– An overall coordination for interworking between the NSIS protocol suite and multihoming capability needs to be discussed further.

• Question:– How should multiple CRNs differentiate the Path Update for multihoming

from the generic Path Update? – How do CRNs authorize multiple flows with different flow identifiers for

the same session?

Open issue #11 Mobility Object

• Description:– The Mobility objects such as ‘Mobility_Event_Counter (MEC)’ and ‘Han

dover_Init (HI)’ can be used to solve the ping-pong type handover and the Invalid NR problem, respectively.

• The MEC field can inform the CRN of which incoming message is the latest.• The HI field can explicitly inform AR (or CRN) that a handover is now initiate

d.– QoS-NSLP flag (e.g., NO_REPLACE flag) may be helpful for a ping-pon

g type handover because of preventing state on the old path from being torn down.

• Question: – Do those mobility objects need to be included in NxLP messages?– Which primitives need to be used in order for NTLP to notify QoS-NSLP

of the mobility events?

Open issue #12 Terminology: Path Update

• Description: – The term, "Path Update" has been chosen since the initial manyfol

ks-draft.– Some folks think that the term does not appropriately represent the

meaning of NSIS state recovery.

• Currently, the candidates for substitution of the term are – "State Recovery" and "State Update".– Any suggestion?

Next steps

• Identify and further clarify the following issues– Tunneling-related issues– Localized signaling issues– Newly found issues– The security-related issues

• 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)