Jarno,
The Carpenter/Conta proposal does include two formats for the label (one aimed
at intserv flows and one aimed at diffserv flows), but if you use the field
only for rapid routing lookup, you don't care about that; in both cases you can treat
the label as 20 opaque bits I think.
You only care which format it is when you are doing specific intserv or diffserv
packet classification.
Brian
[EMAIL PROTECTED] wrote:
>
> Jim,
>
> Nice rant :-)
>
> Could you elaborate on the pseudo-random nature of the flow label. It seems
> to me that if it did not need to be pseudo-random, people could go on
> "signaling off-line" about the flow label values (in SLAs, this seems to be
> what Alex & Brian want). I see no harm in allowing such practice, but it
> would be best if there is only one format for the flow label, as it would be
> faster to decode.
>
> Jarno
>
> > -----Original Message-----
> > From: ext Jim Bound [mailto:[EMAIL PROTECTED]]
> > Sent: 21. elokuuta 2001 15:58
> > To: Thomas Eklund
> > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob Hinden; ipng
> > Subject: RE: Higher level question about flow label
> >
> >
> > thomas,
> >
> > that is why if we can treat the flowlabel as part of tuple with src
> > address and identify a connection which identifies the forwarding path
> > the challenge is reduced. there is nothing needed but the
> > header for the
> > look up and forward. I believe this can be made to work.
> >
> > the traffic class will provide diff serv metric and the flow
> > identifies
> > the E2E connection with the src addr.
> >
> > The src addr MUST be a global address.
> >
> > Site-Local can be done too but don't want to get into that right now.
> >
> > One can ask if the Ipv6 address is global why have the flow for per
> > connection as above. This is a good question and needs discussion.
> >
> > First the flow assists with the lookup in a binary tree,
> > queue type, or
> > archaic hash. Its the hint to the next leaf, bucket, or queue entry.
> > duplicat highorder bits would cause a branch. This could speed up the
> > search before even getting to the global address.
> >
> > The src + flow could also be used as label for MPLS and its
> > in the IPv6
> > header.
> >
> > The business reason could also be that end users would create SLAs for
> > their flow labels in addition the bits set for the traffic
> > class. This is
> > how QOS Int Serv could be realized. And I guess conjunct
> > with diff serv
> > but that would need to be specified too.
> >
> > This also benefits client and server boxes too (gateways
> > too). We can now
> > potentially keep one protocol control block for user connections. tcp,
> > sctp, and dcp per connection data structures would not have to be kept
> > above the internet per connection datastructures (e.g. bsd
> > inpcb would be
> > enough). This is a performance win for clients and servers
> > for IPv6 not
> > just routers or switches or gateways.
> >
> > If we put a length in the flow yes it can be made to work but
> > not without
> > being verified by the router as the packet is parsed or
> > "policed" then we
> > have just put new processing far worse than the IP checksum which we
> > removed from the IPv6 router. And opens up opportunity for
> > bugs at that
> > code point we don't have today.
> >
> > I also don't support the field being mutable as it transits
> > the network
> > path to the end destination.
> >
> > The reason is that we should make IPv6 E2E perform in the
> > network as fas
> > as possible. If you look at all the work to do VPN, L2TP,
> > NAT, Virtual
> > Routing, et al that is emerging pervasive for IPv4 the root
> > reasons are
> > lack of IPv4 address space, the desire to do fast layer 2
> > switching, and
> > security inspection (e.g. firewalls).
> >
> > The later two above are the only valid visions. We need to
> > eliminate in
> > our thinking the mind set developed because of lack of IPv4
> > address space.
> > I could argue that what is happening to IPv4 is pure professional
> > irresponsibility on our part as Internet engineers. The
> > Internet should
> > remain E2E. This is not a politcal comment or even social
> > comment. Its a
> > comment stating my assumptions about how the Internet should operate.
> >
> > I think we need to discuss our assumptions for the
> > requirements with the
> > solutions we define.
> >
> > ADSL box providers actually market that NAT helps you because
> > you don't
> > have to worry about address space. This is absurd and professionally
> > irresponsible in the market. We should stop this with IPv6.
> >
> > The way to do that is give routers the means to forward packets E2E by
> > only looking at the header of IPv6. That is what Brian's "b" solution
> > does. Plus it benefits all nodes besides routes for IPv6 as I state
> > above.
> >
> > As far as IPv6 extensions. The payload length gives the
> > router the entire
> > length of the packet. If the flowlabel can be used to
> > identify forwarding
> > the packet in addition to the address and other parts as I state above
> > then there is no challenge for ASIC vendors for strict
> > forwarding of IPv6
> > packets.
> >
> > If those vendors want to add more value by digging past the
> > header then
> > that is their option to add value but I don't believe it is
> > required for
> > fast forwarding of IPv6 packets.
> >
> > Steve's design works and I believe can be extended with the
> > flowlabell and
> > we can get rid of the mess IPv4 is making of the Internet
> > because of the
> > band-aids being applied.
> >
> > I believe the End System (and that could be a router in some
> > cases or a
> > broker router) should set the flowlabel at the access exit before the
> > edge. But thats another discussion.
> >
> > Another discussion is how do we pick good random numbers for
> > the flowlabel
> > at the access exit end system or even a client.
> >
> > regards,
> > /jim
> >
> >
> > On Tue, 21 Aug 2001, Thomas Eklund wrote:
> >
> > > I agree alex.
> > >
> > > It gets worse for people that are doing ASIC which is not
> > programmable, then
> > > they need to spin a new version their ASIC when the
> > protocols changes. For
> > > people that are doing programmable ASIC (network processors
> > etc) this is not
> > > a problem.
> > >
> > > But common for both approaches is that the header format is
> > really challenge
> > > for the ASIC engineers
> > >
> > > -- thomas
> > >
> > > >-----Original Message-----
> > > >From: Alex Conta [mailto:[EMAIL PROTECTED]]
> > > >Sent: den 20 augusti 2001 22:15
> > > >To: Thomas Narten
> > > >Cc: Brian E Carpenter; Bob Hinden; ipng
> > > >Subject: Re: Higher level question about flow label
> > > >
> > > >
> > > >
> > > >
> > > >Thomas Narten wrote:
> > > >>
> > > >> [...] When someone can make a compelling argument for why
> > > >> the bits need to be defined in a certain way (i.e.,
> > there is a real
> > > >> application for which using the bits provides
> > significant benefits,
> > > >> and those benefits do not appear achievable through
> > other means) that
> > > >> is the time to define the bits. What I do sense with many of the
> > > >> recent discussions surrounding the Flow Label is that
> > there are many
> > > >> folks (i.e., folks putting IPv6 into hardware) that want
> > to know what
> > > >> they should implement w.r.t. the Flow Label. While it would
> > > >be nice to
> > > >> be able tell them what to do, we shouldn't standardize
> > something just
> > > >> for the sake of having a definition.
> > > >>
> > > >> Thomas
> > > >
> > > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, or 3.2
> > > >instructions of a hypothetical
> > > >1Ghz processor which can execute one instruction per
> > cycle. That's a
> > > >hell of a requirement.
> > > >
> > > >As consumers, we all enjoy the very cost-effective availability of
> > > >100Mb/sec line speed packet processing in almost every
> > > >Notebook, or PC.
> > > >
> > > >IP and QoS Engines implemented in silicon, on a chip or a
> > few chips, by
> > > >IBM, INTEL, and many, many others, is one of the reasons of the low
> > > >costs, along with the ability to optimizing the hardware
> > > >in so many more and different ways than the software (for instance
> > > >parallel header, or parallel header field processing).
> > > >
> > > >1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just
> > > >around the
> > > >corner, with 40Gb/sec following not long after.
> > > >
> > > >With such drastic "timing" requirements, implementing engines in
> > > >silicon, and inventing *clever* mechanisms to handle the sequential
> > > >processing of headers alone, will not be sufficient to
> > implement very
> > > >cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a
> > > >disadvantage relative to IPv4.
> > > >
> > > >We need all the help we can get from the protocol, that is
> > headers, and
> > > >their fields, for forwarding and QoS processing, and by that I
> > > >mean both
> > > >Intserv, and Diffserv.
> > > >
> > > >Regards,
> > > >Alex
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
