Basavaraj Patil wrote:
Alex,
On 3/14/07 12:52 PM, "ext Alexandru Petrescu" <[EMAIL PROTECTED]>
wrote:
Basavaraj Patil wrote:
On 3/14/07 12:04 PM, "ext James Carlson" <[EMAIL PROTECTED]> wrote:
Basavaraj Patil writes:
On 3/14/07 11:14 AM, "ext James Carlson" <[EMAIL PROTECTED]> wrote:
That issue is the exclusive use of IPv4 or IPv6 on Packet CS. Why
must it be exclusive? The first four bits of the datagram tell you
conclusively whether you're looking at IPv4 or IPv6, so why is strict
segregation needed?
Not sure I understand what you mean by segregation... The same packet CS is
used for IPv4 as well as IPv6. There are no separate CS' per se.
The classification rules segregate an IPv4 packet from an IPv6 packet and
map it to the appropriate transport connection (CID) over the air
interface.
That's not what I meant.
A single CID using just Packet CS could handle both IPv4 and IPv6
traffic on the same interface.
You'd do this (on the receiver side) by looking at the first four bits
of the inbound IP datagram. They're '4', then it's IPv4. If they're
'6', then it's IPv6. If it's anything else, discard.
Okay.. I see what you mean. I don't really have a comment about it.
Sorry for interfering here, sorry if I misunderstand anything. Just one
thought: terminology.
I think this boils down again to that terminology issue, that longer
IEEE definition of what IETF calls "IPv6 CS". By IEEE, it's actually
"the IPv6 classifiers of the IP specific part of Packet CS". So this
document could be named "Prefix Assignment, Router Discovery, MTU and
IPv6 Addressing for the IPv6 classifiers of the IP specific part of the
Packet CS". Which doesn't make much sense, because one wouldn't run
Router Discovery over some classifiers.
We need that "IPv6 _over_ foo" tint. And these IPv6 classifiers aren't
_a_ foo.
Throughout the IEEE spec these IPv6 specific classifiers are mainly used
for PHS (packet header suppression) and recomposing. This is the most
use of these IPv6 classifiers.
To quite the IEEE spec:
" A classification rule is a set of matching criteria applied to each
packet entering the IEEE std 802.16 network. It consists of some
protocol-specific packet matching criteria (destination IP address, for
example), a classification rule priority, and a reference to the CID.
"
PHS is optional. A packet after classification may be mapped to a specific
PHS rule. If there is a PHS rule, there is the 8 bit PHSI (index) in the MAC
SDU.
So I do not think that classifiers exist solely for the purpose of PHS.
Right, I wrote "mainly", add IMHO.
In this context I'd comment on why IEEE is using this PHS, and not ROHC,
an IETF standardized protocol, for various link-layers. Or maybe any
other IETF-specified header compression (for ppp and for others).
I think we are digressing when we start to discuss why IEEE chose PHS and
not ROHC or something else. I don't see the relevance of discussing IEEE
design decisions in the IETF.
Raj, I think too it sounds indeed far-fetched, and can't be discussed
here IEEE document evolution, IEEE design decisions, etc. not my
intention to disgress.
But at the same time, I think since some time now, that every other use
(other than classifiers) of IPv6 in the IEEE spec is superfluous. For
example all the IEEE entry procedure that specifies IPv6 steps is
superfluous (requires TFTP, TIME protocol, SS management connections,
slaac/dhcp etc).
For classifiers themselves: if PHS classifiers list _some_ IPv6 header
field (Protocol, DSCP, src, dst, ports - that's all) - how can one make
sure that _all_ existing IPv6 headers and extensions get listed in these
IEEE IPv6 classifiers? How can one make IEEE PHS work with Mobility
Header of Mobile IPv6 for example?
You have said at some point that although IEEE spec requires IPv6 to be
established on a Secondary Management Connection, we're somehow free to
ignore that. Which is a good practical way forward. But shows we do
have some privileges to ignore some IEEE IPv6 features, and not others.
I agree with that, just that sometimes it simply doesn't make much sense
to me, that's all.
Alex
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
