1 / 9

Path Type Support for NSIS Signaling

This document discusses the need for path type awareness in NSIS state management, specifically in scenarios involving multi-link terminals and Mobile IP. It proposes the use of Path Type IDs as a solution requirement. The document also discusses related requirements and potential problems in these scenarios.

wiest
Download Presentation

Path Type Support for NSIS Signaling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Path type support for NSIS signaling<draft-sanda-nsis-path-type-01.txt> Takako Sanda, Toyoki Ue, Hong Cheng IETF#61 8 November, 2004

  2. Motivation & Goal • NSIS state management sometimes need to be aware of the path types to achieve appropriate operations • Multi-link terminal: multiple data paths for one session • Mobile IP: triangular path and optimized path • These scenarios cause data path change without MN’s handover or router’s error • Discussing possible problems on the scenarios • Introducing Path Type ID as a solution requirement • Related requirements are also discussed

  3. Problem statement – Multi-link case • MN is using two interfaces (s, t) for one session to communicate with CN. When QoS states are installed, Session ID (SID) is the same for two paths but Flow IDs are different • When an interface ‘t’ performs handover ((1) -> (2)), Path2 should be replaced to Path3, but Path1 should be kept. • How can QNE1 know which path should be released? • One solution would be MN sends the information of paths to be kept (or replaced) with signaling message. But If there are many paths, the information would be big (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

  4. Path Type ID 0x01 Path Type ID 0x02 Path Type ID 0x01 Path Type ID 0x02 Path Type ID 0x02 Proposed solution – Multi-link case • Each QNE has Path Type ID information with other identifiers • Path Type ID is carried by RESERVE message, and stored in QNEs • Path Type ID could be codes or numbers • In this scenario, Path Type ID differentiate MN’s interfaces • Path Type IDs for Path2 and Path3 are the same • QNE1 can recognize that Path2 is old (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

  5. Problem statement – Mobile IP case • Triangular route (path1) is used first and then optimized route (path2) is used • The state for triangular path shouldn’t be removed when the state for optimized route is established • But the state for triangular path may be required to be kept as reduced mode • How can QNE1 and QNE4 recognize that path2 is optimized route? • When MN performs handover, state for new paths will be installed • How can crossover nodes (such as QNE4) know which path should be released? (1) (2) HA QNE3 QNE4 CN HA QNE3 QNE4 CN Path1 Path1 QNE2 Path2 QNE2 Path2 Path4 QNE1 QNE1 Path3 AR1 AR1 AR2 MN MN MN

  6. Proposed solution – Mobile IP case • Each QNE has Path Type ID information with other identifiers • In this scenario, Path Type ID differentiate triangular path and optimized path • So, flexible operation will be possible • For triangular path, Path Type ID for tunneled part may need to be different • Path between HA and CN is fixed while MN and HA is changed by MN’s handover (1) (2) HA QNE3 QNE4 CN HA QNE3 QNE4 CN Path1 Path1 QNE2 Path2 QNE2 Path2 Path4 QNE1 QNE1 Path3 AR1 AR1 AR2 MN MN MN

  7. Related Discussions (1/2) • Which Flow ID should be selected for MIP triangular path? • Different Flow IDs for different section of triangular path • IP addresses pair of HoA and CN is used for fixed part (from HA to CN), and for tunneling part, IP addresses pair of outer header is used ## This is based on the idea that Flow ID is used for packet classifier • Information of MN’s location change is not available for fixed part => Binding information between optimized path and triangular path may be necessary • The same Flow ID for whole triangular path • HoA and CN pair -> Binding information may be necessary • CoA and CN pair -> Binding information is not necessary. Although Flow ID may be the same as optimized route, They can be differentiated by Path Type ID ## This case, Packet classifier other than Flow ID is necessary

  8. Related Discussions (2/2) • Packet classifier other than Flow ID is useful for the following case • There are some scenarios to use several ports for one flow • Flow ID could indicate only one port • If wildcard is employed, it may cause confusion when multiple session are used. • Packet classifier would be able to have flexible structure Port 10001Port 10002 Session 1 Server Port 10003Port 10004 Session 2 Terminal

  9. Conclusion • We propose • Supporting Path Type ID • GIMPS layer or NSLP layer would be relevant • Supporting Packet Classifier other than Flow ID • Some object like FlowSpec would be useful in QSpec Discussions?

More Related