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

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Nov 2006 08:14:39 -0800

Overall, I was quite happy about the document. But
it still needs a revision, mainly to remove things
that it should not be talking about.

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 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.

> 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.
>    specifically defined in a profile B ASN.  However all the functions
>    of an ASN such as the MIP4 FA, AAA, AR exist within the scope of an
We are talking about IPv6 here.
>  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.

See also Section 6.1.
> 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.
> Usually a link is bounded by routers
>    that decrement TTL.
Usually?
> 6.1.  IPv6 link in 802.16
>
>    For 802.16 network, following the 3GPP precedent [RFC3314], point-to-
>    point link model is recommended.
Do not talk about 3GPP here, just make the recommendation. And the
recommendation is not for 802.16, it is for IPv6 over IPv6CS in 802.16
only.

> 6.1.1.  IPv6 link in WiMAX
Make the generic case first, and then formulate the
Wimax as an example or implementation note.

> 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.

There is a statement at the end of this section on
router advertisement. I am assuming that is not
in any way changing the way advertisements work
in IPv6. Correct?

> 6.3.  Maximum transmission unit in 802.16
Compress this section by stating the maximum value
and a default value that is  lower, because of the
expected backhaul arrangements. Also state that
the IPv6 router advertisements or configuration
may indicate other values.
>    On completion of the establishment of the IPv6 link, the MS may send
>    a router solicitation message to solicit a Router Advertisement
>    message from the AR to acquire necessary information as specified in
>    RFC2461 [RFC2461].  An MS that is network attached may also send
>    router solicitations at any time.
This is good stuff, but see below.
> 8.2.  Router Advertisement
>
>    The AR should send a number of router advertisements as soon as the
>    IPv6 link is established to the MS [FRD].
Do not refer to FRD, its not going to be ready soon. See also below...
> 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.
> 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.

>    conected via the 802.16d/e at the link and physical layers.  The IPv6
typo.

--Jari

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

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 8 Nov 2006 02:05:46 +0900

Dear Jari

happy to hear that you're happy.

> effect, as otherwise the negotiation will not be helpful.

this is tricky. 802.16 defines several CSs such as ATM Cs, IP CS,
Ethernet CS, 801.1Q VLAN CS... Shall the network support all of them?

> specifications, but please point to them.

ok.

> GRE tunnel is not on a per-MS basis.

This is general WiMAX statement. For IPv6 operation, we explicitly
recommended tunnel granuality to be 'per MS' or 'per flow' in Sec 6.1.

> can uniquely identity which MN a packet comes from.

I see.

> > Usually a link is bounded by routers

RFC 2461 mentions a link without a router. That's why we put 'usually'.

> recommendation is not for 802.16, it is for IPv6 over IPv6CS in 802.16

ok.

> Wimax as an example or implementation note.

That was our intention. The part immediately following 6.1

   For 802.16 network, following the 3GPP precedent [RFC3314], point-to-
   point link model is recommended.  In 802.16, there exists L2 layer....

describes the generic case. We added Sec 6.1.1. as a specific example of WiMAX.

> in any way changing the way advertisements work

yes.

> Do not refer to FRD, its not going to be ready soon. See also below...

Because of that, we put FRD in Informative References.

> currently). Don't do it in this document.

ok.

> I would just delete this part.

Taking our tight schedule into account, it would be better to remove
'router lifetime' part from the document.

> >    conected via the 802.16d/e at the link and physical layers.  The IPv6

thanks.

Best Regards

JinHyeock

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Nov 2006 09:17:25 -0800

> Ethernet CS, 801.1Q VLAN CS... Shall the network support all of them?
I was only thinking of requiring support for the ones
that are in the 16ng charter.
> recommended tunnel granuality to be 'per MS' or 'per flow' in Sec 6.1.
Right. So make that clear -- I would suggest deleting the
confusing text.
> describes the generic case. We added Sec 6.1.1. as a specific example
Right. But I'd like to see the text condensed. Do not have
two subsections, have one with the max and the recommended,
followed by a brief note about the rationale.
> Because of that, we put FRD in Informative References.
Does not go far enough for this case, in my opinion.

--Jari

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 30 Nov 2006 13:18:17 -0600

Jari,

Responses to your comments inline:

> that it should not be talking about.

A revision is essential based on your and other comments that I have
received as a result of the WGLC.

>   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.

> 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.

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.

> 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.

> We are talking about IPv6 here.

Agree. This is an editorial mistake. Will be fixed.

> 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.

> See also Section 6.1.

Okay.

> 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.

>> Usually a link is bounded by routers

Typo.

> recommendation is not for 802.16, it is for IPv6 over IPv6CS in 802.16

Agreed. This was also suggested by Daniel. And it will be fixed.

> Wimax as an example or implementation note.

Okay.

> 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.

> in any way changing the way advertisements work

Yes.

> may indicate other values.

Ok.

> This is good stuff, but see below

> Do not refer to FRD, its not going to be ready soon. See also below...

Ok.

> 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.

> 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?

>>    conected via the 802.16d/e at the link and physical layers.  The IPv6

Ok.

Thx for the comments.

-Raj