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]
--------------------------------------------------------------------
