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

From: "Riegel, Maximilian" <[email-masked]>
Date: Fri, 26 May 2006 18:19:29 +0200

The WiMAX NWG has considered the coexistence of multiple types of CSs in
a basestation, but never multiple types of CSs on one link. The
assumption is that a particular terminal uses one type of CS on its link
to the basestation, but a basestation may have to handle multiple CSs in
parallel.
This is similar to the case that a host is connected by one type of link
(ETH or PPP) to a router, but the router has to handle PPP-interfaces as
well as ETH-interfaces in parallel.

In WiMAX NWG, it is an option that the network supports both, but it is
not mandated.

Bye
Max

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Syam Madanapalli
Sent: Friday, May 26, 2006 9:56 AM
To: 'Jari Arkko'; [email-masked]
Subject: RE: [16ng] multiple CS issue - proposed way forward

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.

> -----Original Message-----
> From: [email-masked] [mailto:16ng-
> [email-masked]] On Behalf Of Jari Arkko
> Sent: Friday, May 26, 2006 2:26 AM
> To: [email-masked]
> Subject: [16ng] multiple CS issue - proposed way forward
> 
> 
> 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.
[Syam Madanapalli] 

As mentioned above, we need to decide if we allow the co-existence
two devices on the same link with different CSs.

> 
>     Possibly, if we can agree on this, a
>     set of mandatory to implement
>     CSes on the network side.
[Syam Madanapalli] 

It is a good idea to recommend for network to support both the CSs.
In WiMAX Forum, NWG mandates that the Network must support both the CSs.

Thanks,
Syam

> 
> 5. Add more details about the EthCS
>     specification scope.
> 
> Comments?
> 
> --Jari
> 
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: "Syam Madanapalli" <[email-masked]>
Date: Mon, 29 May 2006 10:20:47 +0530

Hi Max,

Having separate subnet/link for different CSs is good idea; the
packets between CSs will be routed. And I hope NWG has taken
precautions for assigning
(separate) prefixes for each CS. Also each CS requires different multicast down
streams (multicast CIDs) if downlink multicast is used.

Thanks,
Syam