Jarno,
Exactly. Treating the (IANA-registered) PHB ID values as part of a "well-known
flow label" space is a good idea. We would need to agree on the flow-label
semantics being
a) end to end
b) not authenticated (hence cannot prove the end-to-end property)
c) split into "well-known" and "locally assigned" halves
c) is a change from RFC 2460.
Brian
[EMAIL PROTECTED] wrote:
>
> Jim,
>
> Could you help my memory on Steve's counter arguments? From the meeting
> minutes I just read that you "agree with Steve's position". Also, according
> to the minutes, while the division in two was similar, there is a difference
> in the intended semantics between your proposal and Brian's ("Router owns
> it" vs. "Non-unique value").
>
> Anyway, I kept thinking about this over the weekend. I think we just need to
> agree on what a "flow" is, or what it could be. In intserv we have
> "micro-flows" (being specified by the 5-tuple). In 2460 App.A we have an
> "app-to-app" flow, which is agnostic to the transport header stuff, but
> needs to be given the same forwarding treatment (including routing).
>
> (Since the first is a subset of the second, we only need the "app-to-app"
> flow, as the micro-flow can be achieved by a host convention of mapping 1:1
> between a 5-tuple and a flow label.)
>
> I think we could have a new kind of flow, a "well-known flow". The prime
> example of this kind of the flow is the one with flow label '00000'. For
> these the source only requests the same forwarding treatment, but naturally
> excluding routing if destination addresses are different. The state for
> these flows could be either SLA based or signaled.
>
> For administrative reasons the flow label name space should be split in two,
> as Brian proposed, but with the MSBs reversed: MSB='1' for 2460 App.A flow
> (but without the PRN requirement), MSB='0' for the "well-known flows".
>
> As discussed, the "well-known flow label" should be immutable as well as the
> "app-to-app" flow label. (We do not need another DSCP field.)
>
> The "well-known flow label" would be an end-to-end construct, and would be
> meaningful only in a context of a (transitive) business relationship to
> either the source or the destination. This means that an ISP would only look
> at the flow label, if a customer tells it to. The SLA (or signaling or
> whatever) binding together a (range of) source address(es), a (range of)
> destination address(es), and a specific "well known flow label", would also
> tell what to do with the packets of the flow.
>
> The property of being "well-known" would help otherwise unrelated end points
> to agree on what values to use (without signaling), and enable off-line
> configuration of those diffserv reclassifiers on domain entry.
>
> What Brian has proposed is that a portion of the "well-known flows" name
> space to be allocated to PHB-IDs. Others could have other ideas for
> well-known flow labels (like Christian's "traffic type"). Inevitably the
> specification of the well-known flow label hints at the intended semantics,
> but it should be clear that the semantics is meaningful only if a "paying"
> customer can be identified (directly or indirectly), and even then the
> customer tells what to do with the packet (E.g. Could map an AF-PHB-ID flow
> label to EF DSCP value).
>
> In some business arrangements between an end user and an ISP, usage of
> specific "well-known" flow labels could result in a better service and incur
> additional charges. Therefore the use of the "well-known" flow labels must
> be separated from the usage of the well-known ports of the transport layer.
> Also, it may be that the user wants to pay extra for the delivery of some
> packets over e.g. HTTP, but NOT for others.
>
> As for the HW implementations, it seems that wildcard source address for
> matching a packet with a "well-known flow label" doesn't make too much sense
> (*). So, the implication would be that your lookup needs to be agnostic of
> the flow label format altogether, just treat it as 20 bits of random (but
> not PRN) data. The data you find should tell what to do with the packet. The
> SLAs and intserv signaling is used to populate that data.
>
> (* In the beginning of the path, you need to know who is sending the packet
> (to decide whether to do what the flow label asks for). At the end of the
> path, the customer doesn't want to pay extra for some random hacker sending
> packets with a "well-known flow label". So, in both cases, the source
> address needs to be "in range".)
>
> >From the IPv6 WG perspective the only difference between the two forms is
> the missing 'routing' aspect of the forwarding treatment based on the
> well-known flow label (same label can be used in packets to multiple
> destinations. The state establishment for the actual use of the flow labels
> is outside of the IPv6 WG scope (IMO).
>
> So, once defined as a concept, the definition of the actual "well-known
> flow-label" values should not be a critical issue for the IPv6 WG. Naturally
> any large scale benefits of the concept depend on widely agreed upon
> definitions, but even single "big customers" could have specific values as
> part of their SLAs with their ISPs.
>
> Jarno
>
> > -----Original Message-----
> > From: ext Jim Bound [mailto:[EMAIL PROTECTED]]
> > Sent: 31. elokuuta 2001 19:20
> > To: Brian E Carpenter
> > Cc: ipng
> > Subject: Re: Another idea for the flow label
> >
> >
> > Brian et al,
> >
> > A lot of mail but lots of it are repeating. The only way my change in
> > vote for "c" will work is if we do this below per Brian. But
> > I presented
> > this case in front of the IETF WG at Minneapolis and folks
> > did not want to
> > go there and Steve presented good counter arguments to doing
> > it. It is a
> > compromise to do the below.
> >
> > A few statements:
> >
> > Immutable field: I agree with Tony 100% if we have a per microflow it
> > should be immutable for that option and I mean in the strongest sense
> > that it is read-only. I will not post my reasons again but
> > they are in
> > line with Tony and also that I am not comfortable saying
> > nodes along the
> > path will return the field to its former value. AT
> > ALL.......Causing bugs
> > with per microflows for apps that depend on it is something I
> > could never
> > support and to trust the edge and core with that without how its to be
> > done is a bit of a stretch for me and I think for any IETF
> > specifications
> > sound protocol effect on networks. Immutable field is the
> > quickest way to
> > standards track I would argue for per micro-flows. In the
> > future after
> > some practical experience that could be re-discussed.
> >
> > MF Classifiers: We should solve this problem so that all
> > classification is
> > done only at the header. The multiple tuple value for classification
> > beyond the header in Diffserv architecture was a huge mistake
> > to put in
> > the model and having boxes look at L4+ values is bordering
> > absurdity IMO.
> >
> > IETF Rants we need to support QOS other standards: This is
> > simply bogus
> > logic. As Bob said the place to change our rules is in
> > POISED not IPng.
> > If Diffserv made a mistake or neglected to deal with cases
> > like IPsec that
> > does not mean IPv6 WG MUST support fixes to make it work. That is the
> > bogus logic. It assumes a rule for us in IPv6 WG which DOES
> > NOT EXIST.
> > Arguing it may be the right thing to do is fair. I don't
> > agree though.
> >
> > Are we getting anywhere? After working on this for many
> > years I feel NO.
> > The bottom line is can the IPv6 WG agree to the attached compromise in
> > some form? That should be the first thing we have to agree
> > on or Thomas
> > is correct we need to just leave it alone for awhile till we can get
> > consensus. We don't have it now IMO.
> >
> > Should we use the flow for other than QOS? I think that is a
> > wise vision.
> > But then we need some kind of compromise for that too.
> >
> > /jim
> >
> >
> > On Tue, 28 Aug 2001, Brian E Carpenter wrote:
> >
> > > How would people feel about this encoding for the flow label
> > > (deemed to be immutable end to end)?
> > >
> > > 0 1
> > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |0| Per-microflow unique value |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >
> > > 0 1
> > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |1| Non-unique value |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > > I'm not yet 100% convinced that the second case is sufficient for
> > > diffserv, but at least it would be a more generic approach
> > > than reserving half the space for diffserv.
> > >
> > > Brian
> > > --------------------------------------------------------------------
> > > 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]
> > > --------------------------------------------------------------------
> > >
> >
> > --------------------------------------------------------------------
> > 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]
> > --------------------------------------------------------------------
> >
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
On assignment for IBM at http://www.iCAIR.org
Board Chairman, Internet Society http://www.isoc.org
"We shall need a number of efficient librarian types
to keep us in order." - Alan Turing, 1947.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
