Subject: [16ng] multiple CS issue - proposed way forward

From: Jari Arkko <[email-masked]>
Date: Thu, 25 May 2006 23:55:53 +0300

We've discussed the issue of the multiple CSes
on this list, based on comments from the IESG
and by others.

What follows is my personal suggestion on a
possible path forward and I would like to get
feedback from you whether this is acceptable.

We know we are going to have multiple different
CSes in real life. In the future possibly more than
what we have now. But I'm getting the feeling
that its not easy to agree on a global mandatory-
to-implement option for both peers. The main
reason for this is that for better or worse, IPCS
will be used for the mobile/single device
deployment whereas the EthCS is easier to use
in, say, DSL replacement scenario by bridging
it to a an in-home Ethernet.

However, it is easy to mandate the ability to
negotiate the options. Some, possibly all of
this functionality is already in 802.16. It might
also be possible to mandate the support of
multiple options at the network side this
would make interoperability much easier.
Such mandates would apply only to
implementations, however. Its possible
that there is no configuration on the
operator's network that would allow
another type of CS to be used. Also,
if the different CSes are used in very
different devices and networks, such
mandate would not have much value.

I'm also getting the feeling that choosing
different standard status for the options may
not be the best approach. They both deserve
to be documented in a PS level document,
and personally I'd have some reservations
about recommending either one as the only
PS.

Finally, I believe we need to specify better
what the IP over EthCS really means in
terms of specification effort. In the DSL
replacement scenario, for instance, IP/ARP/ND
behaviour needs to be the same as we
already have, assuming we may be bridging
to regular Ethernet. So it seems that
we are mainly talking about how bits
are arranged in 802.16 so that the
end result can be mapped to regular
IP over Ethernet. Its unclear to me exactly
how much such specification work remains;
presumably there's still some left, such
as details about compression? But
the scope is much narrower than in the
IPCS case. It would also be useful to
understand what the ambition level is
for, say, introduction of advanced
compression schemes for IP over EthCS.

So, I would suggest the following:

1. Handle both EthCS and IPCS work in the WG.

2. Shoot for Proposed Standard for both.

3. Require a negotiation mechanism
    for the CS selection.

4. No mandatory to implement CS for
    the client side.

    Possibly, if we can agree on this, a
    set of mandatory to implement
    CSes on the network side.

5. Add more details about the EthCS
    specification scope.

Comments?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 May 2006 12:43:30 +0300

Yes, this indeed is something that needs to be understood.
>From a charter text perspective it may be enough to state
that the specifications have to provide an explanation of
how the CSes are selected for a particular link or packet.
(In terms of the actual specifications, one option would
be consider different simultaneous CSes as different
interfaces.)

--Jari

Syam Madanapalli wrote:

>Hi,
>
>One point that may be missing here is the implications of
>Co-existence of multiple CSs on the same link. If we allow
>two devices on same IP Link, one with IP CS and other with 
>Eth CS, we may need to see how the on-link communication works.
>  
>