40 likes | 170 Views
Some issues for NSIS signaling <draft-sanda-nsis-path-type-02.txt>. Takako Sanda, Toyoki Ue, Hong Cheng IETF#62 March, 2005. Issue - multiple paths support. In certain scenarios, one terminal may use multiple data routes for one session Multi-link terminal Mobile IP route optimization
E N D
Some issues for NSIS signaling<draft-sanda-nsis-path-type-02.txt> Takako Sanda, Toyoki Ue, Hong Cheng IETF#62 March, 2005
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 (1) (2) CN CN Path1 Path2 Path1 Path2 SID: XFlow ID: A QNE1 SID: XFlow ID: B SID: XFlow ID: A QNE1 SID: XFlow ID: B Path3 Nw1 Nw2 Nw1 Nw2 SID: XFlow ID: C AR1 AR2 AR1 AR2 AR3 s t s t MN MN
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
Way forward • Multi-path support issue needs to be address in the GIMPS and Applicability Statement Draft • To guarantee that the NSIS wont break in the listed scenarios • Flow ID generation issue needs to be addressed in the GIMPS or QoS NSLP • Ways 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