The capture of the type of application is in fact the idea behind the
IANA reserved/defined value of the "flow label type' in my "flow-label"
related recent draft. The first bit of the redefined
"flow label type" would indicate that it is a IANA number as opposed to
a "protocol/server-port". This "reserved/IANA defined" value is a better
indication than the "protocol/server-port".
Alex
Christian Huitema wrote:
>
> Brian Carpenter wrote:
> >
> > Francis Dupont wrote:
> > >
> > > In your previous mail you wrote:
> > >
> > > - figure out a way to make the other option in Alex's draft:
> > >
> > > 0 1
> > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |0| Server Port Number| H-to-H protocol|
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > > suitable for use by policy-driven diffserv classifiers.
> > >
> > > => can you explain why it is not enough to use the SPI in place of
> > > higher layer selectors?
> >
> > The SPI doesn't have the semantics. A QOS classifier needs to *know*
> > the port and protocol numbers; that's how it takes its decisions.
> > For example you might put traffic with protocol number 30 in a
> > different class from traffic with protocol number 41.
> >
> > Alex's idea of using "server port number" is in fact
> > interesting, since it would allow you to classify traffic
> > on its original well-known port #, without having to rely
> > on dynamically assigned port #s for classification.
> > I'm beginning to think he may be right. But I suggest
> > allocating 11 bits to the port number and 8 to the
> > protocol number, so that we can cover at least
> > some of the registered ports (up to 2047). But the flow
> > label isn't long enough for everything we need.
>
> What is useful for the policy decision is to have an indication of the user
> priviledges and then an indication of the application. Most policy decisions
> are about given some users some guaranties that they can run some
> applications. Addresses are only approximative indications of the users --
> think about proxies, mobility, etc. -- and ports are only approximative
> indications of the application -- think about floating ports, applications
> multiplexed over HTTP, etc.
>
> Having a protocol + port indication in the flow id is a way to provide an
> indication about the indication. But we can do better than having a protocol
> + port tuple. What we really want is some registry of applications, into
> which we could fold the registered ports; then, once the registration
> becomes well known, it becomes easy to write rules that allow for packet
> classification. If we start from this registration perspective, then we want
> a format that allows for several classes:
> * Inherit registration from current registration of TCP and UDP ports --
> probably two
> classes,
> * One class registration of new applications, e.g. provide codes for those
> applications that
> currently work on floating ports,
> * One class for non-registered applications, allowing for experimentation,
> * A null label for users who don't want to disclose what application they
> are running.
> If we do that, then the end system can easily set the application code, and
> the intermediate routers can easily use them.
>
> -- Christian Huitema
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
S/MIME Cryptographic Signature
