1 / 7

NSIS Flow ID and packet classification issues

NSIS Flow ID and packet classification issues. <draft-cheng-nsis-flowid-issues-02.txt>. Hong Cheng, Qijie Huang, Takako Sanda, Toyoki Ue IETF#64 Nov, 2005. Motivation & goal. Address issues of packet classification information signaling MRI is not adequate

kimimela-evans
Download Presentation

NSIS Flow ID and packet classification issues

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. NSIS Flow ID andpacket classification issues <draft-cheng-nsis-flowid-issues-02.txt> Hong Cheng, Qijie Huang, Takako Sanda, Toyoki Ue IETF#64 Nov, 2005

  2. Motivation & goal • Address issues of packet classification information signaling • MRI is not adequate • To achieve a general solution for different NSLPs

  3. MRI & Packet Classification • A separate packet classifier is needed above NTLP • The MRI does not always contain adequate information for both routing and packet classification • Packet classification information covers winder than MRI • E.g. Address wildcarding; a range of ports, etc • Packet classification needs more specific information than MRI provides • E.g. It needs to use upper layer info which is not in MRI • NSLP Application may want to signal some flow not indicated by MRI • E.g. Address than cannot be wildcarded, but they will pass the same NSLP node; aggregation; or off-path case

  4. Why PACKET_CLASSIFIER object is not enough • Issues for the current PACKET_CLASSIFIER in QoS NSLP • It is too coarse • only simply specify which field of the MRI to use • e.g. cannot indicate a range of port address, or addresses wildcarding • It does not provide any extra information • everything is still derived from from MRI

  5. Extended classifier object • more specific information is needed • an extended classifier object is needed • It is generally useful for all NSLPs • The signaling of more specific packet classification information is useful for other application • It should be made generic (not NSLP application specific) • The extended classifier object does not need always be present • for efficiency considerations (MRI is adequate sometimes) • an extended_classifier flag could be used to indicate its presence

  6. extended classifier object issues • NAT traversal issues for the classifier object • Difference NAT requirements when placed at difference layer • NSLP is the suitable place • tradeoff between NAT complexity and signaling overhead, reusability • Consistent rule has to be applied • same rules to apply on MRI and the classifier object

  7. Next step and open issues • An extra/extended classifier object is needed (besides MRI) • How should the issue be addressed? • A general NSLP solution? • To be solved separately in different NSLP applications • More than one classifier object? • Signal more than one address pair (not from MRI) • Stacking of classifiers • when QSPEC stacking is required (and classifier is not in QSPEC) • Does this needs to be supported?

More Related