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. > > I'm noting that you don't need to make a given Packet CS instance > exclusively IPv4 or IPv6, and I'm asking why this wasn't discussed. > Is it because segregation by way of CID is seen as being a superior > mechanism? If so, that's fine, but I think it'd be good to document. The 802.16 group in IEEE made such a choice and design. So I really do not know the reasoning why this mechanism was chosen. I don't know if it makes sense to document here the reasons why IPv4 and IPv6 CS' are segregated, because it is more of an L2 issue and this document is only specifying operation over what has been defined at L2. > >>> Can't both run on the same link? >> >> I guess you mean both IPv4 and IPv6 packets on the same transport connection >> (CID), right? > > Yes. > >> Why would you want to do that even if you could? > > Because it's simple ... ? Agree. > >> It is cleaner >> to setup separate transport connections and use specific classifiers for >> each of these which gives you more control over the type of QoS or bearer >> for each. > > That's interesting. Would one expect IPv4 and IPv6 to get different > QoS treatment? Possible. Both the connections could have the same QoS or request that the radio bearers for v4 and v6 CIDs be different. It depends on what type of QoS is requested for each connection. > >> But to answer your question more specifically: >> No. When the transport connection is established there is a parameter which >> specifies the CS that the connection will use and it is specified in Sec >> 11.13.19.1 of IEEE P802.16-REVd/D5-2004. The options in the table indicate >> that the connection will support only IPv4 (1) or IPv6 (2) etc. > > Right; I'm asking why it's being done that way. (Or, more > specifically, why there doesn't seem to have been any discussion. > Perhaps the discussion was held at the IEEE?) > I guess this is an IEEE specific question and maybe people who were involved in the design (DJ? et al.) can comment. >>> (I'm also a bit concerned that this proposal will end up rediscovering >>> RFC 1547 over time, as other unnegotiated point-to-point mechanisms >>> have in the past, and the reasons why PPP's negotiation exists. I'm >>> certainly not arguing for the use of PPP over Ethernet CS -- that'd be >>> worse still -- but I think the IEEE may have made a mistake in >>> defining an IP Packet CS rather than a PPP Packet CS.) >> >> IEEE is specifying what is called as GPCS (generic packet CS) and I think >> that some of these will be addressed therein. > > OK. > > In that case, my concern would be for interoperability. Having three > or four ways to do something is much worse than having one. This has been raised as a concern previously as well (I believe there was a draft by Bernard Aboba expressing concerns about this as well). At the present time however IP CS is the default mode/CS for transporting IP and as such is being built in base stations and hosts. GPCS is not complete yet. -Raj -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
