Some issues for NSIS signaling

<draft-sanda-nsis-path-type-02.txt>

Takako Sanda, Toyoki Ue, Hong Cheng

IETF#62

March, 2005

2

Issue - multiple paths support• In certain scenarios, one terminal may use multiple data routes for

one session Multi-link terminal Mobile IP route optimization

• In this case, current NSIS Session ID and Flow ID could not provide sufficient support for the path differentiation/manipulation

• Some way to differentiate “Path Type” will be necessary

CN

MN

SID: XFlow ID: A

(1)

s t

AR1

Nw1 Nw2

CN

MN

(2)

s t

AR2AR1

Nw1 Nw2

AR2

QNE1 QNE1

AR3

Path1 Path2

Path3

SID: XFlow ID: B

SID: XFlow ID: A

Path1 Path2SID: XFlow ID: B

SID: XFlow ID: C

3

Issue – Flow ID generation & addresses• In the current NSIS protocol, the Flow ID is assumed:

To be generated based on addresses involved in the communication

Used for data traffic classification

• However, it has some problems in following scenarios:State pre-establishment, using of proxy, etc

- No detail addresses information to generate Flow ID for the first NSIS message

The case an application layer uses multiple ports for one session- A single Flow ID cannot represent all the classification

information, e.g. several ports that cannot be presented using wildcard

4

Way forward

• Multi-path support issue needs to be address in the GIMPS and Applicability Statement DraftTo guarantee that the NSIS wont break in the listed

scenarios

• Flow ID generation issue needs to be addressed in the GIMPS or QoS NSLPWays to generate and handle the Flow ID and its

relationship with actual communication addresses needs to be clearly defined

May relates to the QSPEC work