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