Subject: RE: Usage of IPv6 flow label

From: Christian Huitema <[email-masked]>
Date: Fri, 1 Dec 2000 09:56:46 -0800

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Dec 2000 14:21:30 -0600

Christian,

see below...

> the intermediate routers can easily use them.

Yes, some of these thoughts ran through my mind when I saw Alex's
"IANA Assigned" field. But this amounts to proposing a whole new
QOS classification mechanism, in addition to the existing one,
which is only needed for the case of encrypted IPv6 packets. 
If we can do something like Alex's port/protocol proposal, we can 
trivially map the flow label into existing classification rules (with
a wild card or two).

  Brian

---

From: Alex Conta <[email-masked]>
Date: Wed, 06 Dec 2000 11:48:14 -0500

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Dec 2000 10:05:29 -0600

> indication than the "protocol/server-port".

I think that's debatable, but you need to debate it over in the Transport
and Management areas with all the QOS and QOS management experts. It's clearly
out of this WG's core competence to take that decision.

  Brian