Subject: [16ng] Re: some comments on draft-ietf-16ng-ipv6-over-ipv6cs-01.txt

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Dec 2006 20:44:27 +0200

Basavaraj,
>> Here are the comments:
>>
>> Section 4 needs to fulfill the conditions of this
>> WG's charter, i.e:
>>
>>   The ability to negotiate the used Convergence Sublayer is
>>   required, as no single mandatory CS can be specified for the clients.
>>     
>
> This statement in the charter is ambiguous and I am not sure what the intent
> is. 802.16e specifies the Packet CS which has the IP specific part as well
> as 802.3 and 802.1Q specific parts to it. Capability exchange between the MS
> and BS is accomplished via .16 signaling. However there is really no
> negotiation of the convergence sublayer to be used. Additionally I think
> there has been some degree of confusion w.r.t the CS'. There is not really
> an IPv6 CS, IPv4 CS, 802.3CS and, 802.1Q CS. All you have at the present
> time are two CS', ATM CS and Packet CS. IEEE is also in the process of
> specifying a Generic Packet CS (GPCS), but lets not worry about that for the
> moment. The Packet CS is of interest in the current scope. To quote from the
> IEEE P-802.16-RevD/D5-2004 spec (for information purposes), Section 5.2:
> "
> The packet CS resides on top of the IEEE Std 802.16 MAC CPS. The CS
> performs the following functions, utilizing the services of the MAC:
> a) Classification of the higher layer protocol PDU into the
> appropriate connection
> b) Suppression of payload header information (optional)
> c) Delivery of the resulting CS PDU to the MAC SAP associated with the
> service flow for transport to  the peer MAC SAP
> d) Receipt of the CS PDU from the peer MAC SAP
> e) Rebuilding of any suppressed payload header information (optional)
> The sending CS is responsible for delivering the MAC SDU to the MAC
> SAP. The MAC is responsible for delivery of the MAC SDU to peer MAC
> SAP in accordance with the QoS, fragmentation, concatenation and other
> transport functions associated with a particular connection¹s service
> flow characteristics. The receiving CS is responsible for accepting
> the MAC SDU from the peer MAC SAP and delivering it to a higher layer
> entity. 
> The packet CS is used for transport for all packet-based protocols
> such as Internet Protocol (IP),  Point-to-Point Protocol (PPP), and
> IEEE Std 802.3 (Ethernet).
> "
>
> The last sentence has been modified since its publication and what we have
> now is IP, 802.3 and 802.1Q (i.e no PPP).
>
> Basically what I would like to emphasize is that there is really no
> negotiation of any specific CS. The transport connection (identified by CID)
> that is established between the MS and BS is associated with either the IP
> specific part of the packet CS or 802.3/802.1Q specific parts. Upper layer
> protocols then associate with the appropriate SAP in the MAC layer.
> Classifiers are used to channel packets from the UL to the appropriate CID.
>   
Well, I don't really care how all this happens but the bottom
line is that your document has to explain how the end points
decide to use either IPv6CS or EthCS -- and configuration or
other magic is not entirely satisfactory answer. Feel free
to refer to 802.16 documentation on this issue, but the
IESG needs to be convinced that this part works.
>> This implies that we have negotiation, which you do
>> explain later. But you should highlight that at the
>> beginning. Secondly, you need to say that the network
>> needs to support all the CSes or something to that
>> effect, as otherwise the negotiation will not be helpful.
>>     
>
> If you are refering to the link establishment section (6.2), what I mean to
> say here is that after capability exchange (and ensuring support for the IP
> specific part support (and IPv6 aspect of IP) on the MS and BS sides), a
> transport connection for carrying IPv6 packets over the .16 link is
> established. So in step 2 of Sec 6.2 I would rephrase the sentence as
> follows:
> "
> 2. MS and BS perform capability exchange as per 802.16 procedures. The CS
> capability parameter indicates which classification/PHS options and SDU
> encapsulation the SS supports. By default, Packet, IPv4 and 802.3/Ethernet
> shall be supported, thus absence of this parameter in REG-REQ (802.16
> message) means that named options are supported by the MS/SS. Support for
> IPv6 over the IP specific part of the packet CS is indicated by Bit#2 of the
> CS capability parameter.
>   
I think this is correct.
> The subsequent steps in this section need to be revised as well and I will
> work on that in the revised I-D.
>
> But I would like to get your agreement that we will not specify any CS
> negotiation in this document.
>   
There is no need to specify new negotiation in this
document if one already exists at lower layers. But
the peers need to be able to decide, at a system level,
that they are running either ethernet or IP.
>>> Table of Contents
>>>       
>> I did not find an explanation from the document that
>> would talk about what the actual encapsulation of IPv6
>> packets is. I understand that this is defined in 802.16
>> specifications, but please point to them.
>>     
>
> Okay. I can clarify in the document.
> Basically the 6 byte MAC header encapsulates the IPv6 payload and is carried
> over the air interface.
>   
Right.
>   
>>>  The granularity of the GRE tunnel can be on a per flow
>>>    basis, per MS basis or on a BS basis.  The protocol stack in WiMAX
>>>    for IPv6 is shown below:
>>>       
>> I do not understand how the our link model works if the
>> GRE tunnel is not on a per-MS basis.
>>     
>
> The tunnel has to be on a per-MS or a per-Service flow basis. It cannot be
> at the granularity of per-BS. So I agree with your comment. Note that the
> per service flow granularity is even finer grain than per-MS and will work.
>   
That's OK. Looking forward to the new text.
>> See also Section 6.1.
>>     
>
> Okay.
>
>   
>>> Section 5
>>>       
>> I would suggest either removing this entire section or moving it to
>> an appendix as an example, and stating instead what the requirements
>> for the MN - AR connection are: its a point-to-point to link where the AR
>> can uniquely identity which MN a packet comes from.
>>     
>
> I agree. Let me see if I can move this section to an appendix and still keep
> the explanation clear in the main body. Will try.
>   
Good.
>>> 6.2.  IPv6 link establishment in 802.16
>>>       
>> This seems to talk about things that are specified in 802.16
>> and Wimax. Is there an IP related behaviour here? If not,
>> move this to an appendix or make it clear that its an illustration
>> for the purposes of giving an example.
>>     
>
> The reason for this is because I need to show how the link between the MS
> and AR is established. The PtP link is a combination of the transport
> connection (identified by CID) over the air interface and the L2/GRE tunnel
> (identified by the GRE key) between the BS and the AR. So I think it is
> relevant as written now. However it needs to be updated as mentioned above
> in this email.
>   
I'll take a look at the new text and see.

>>> The AR may send
>>>    unsolicited router advertisements periodically as specified in
>>>    RFC2461 [RFC2461].  However to conserve the battery lifetime of hosts
>>>    and to conserve radio resources over the air interface, unsolicited
>>>    router advertisement transmission are not recommended.
>>>       
>> I'm not convinced that there's a need to do anything
>> special here. If you have the MS perform a router solicitation
>> then you already cover most of the cases; the rest is
>> only about how to configure the router for periodic RAs.
>> That's an orthogonal discussion. If there's a need to
>> change the upper limits in RFC 2461bis that will be done
>> (there is a last call discussion about that point going on
>> currently). Don't do it in this document.
>>     
>
> Okay... But as you can see the current discussion on 2461bis it seems to be
> leaning towards specifying such values in "IPv6 over foo" specific
> documents.
>   
You can do it here, then.
>>> 8.3.  Router lifetime and periodic router advertisements
>>>
>>>    The router lifetime should be set to a large value, preferably in
>>>    hours. 802.16d/e hosts have the capability to transition to an idle
>>>    mode in which case the radio link between the BS and MS is torn down.
>>>    Paging is required in case the network needs to deliver packets to
>>>    the MS.  In order to avoid waking a mobile which is in idle mode and
>>>    consuming resources on the air interface, the interval between
>>>    periodic router advertisements should be set quite high.  The
>>>    MaxRtrAdvInterval should be configurable to a value which is greater
>>>    than 1800 seconds.
>>>       
>> I would just delete this part.
>>     
>
> Hmmm... We need to have this. Because of Idle mode capability of the 802.16
> link, we need to mention a value greater than what is specified in 2461bis.
>
> Would it be okay if I specified a value for the MaxRtrAdvInterval that is of
> several hours?
>   
Within the limits discussed in the 2461bis case? Sure.

--Jari

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