Subject: [16NG] FW: Review of the ipv6-over-ipv6cs draft

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Jan 2007 15:57:44 +0200

Hi all,

I asked Pekka Savola to review this specification,
which he did -- thank you! You will find his comments
below. Please send any responses or text updates
with respect to his points to the list.

Jari

(Sorry for the duplicates, I forgot to copy the list
when sending this.)

-----

The editorial clarity could have been somewhat better.

It is not obvious whether the scenarios where "MS" is a fixed station
and/or a router has been adequately considered or whether this is an
editorial issue.

The design implications of raising RA intervals (intead of, say, filtering
extra RAs out) may not be fully understood.  How are other protocols (e.g.,
periodic MLD reports, Neighbor Solicitations due to port scanning or
pinging
the all nodes multicast address, etc.) handled?

There seem to be some technical problems (e.g., GRE tunnel multiplexing,
different MTU recommendation) with Appendices and an issue of
clarity why the appendices are there to begin with.

It is not clear if traffic classification is adequately specified (or is
it specified elsewhere?) and some miscellaneous issues.

substantial
-----------

==> looking at the other "IPv6 over foo" documents, this document doesn't
specify or mention the following:
 - link-local address generation  (exactly as described in RFC2464, I
suppose?)
 - unicast and multicast address mapping

Maybe these don't require much text but an explicit note might be a good
thing to have.

...

The packet CS defines a set of classifiers that are
   used to determine how to handle the packet.  The IP classifiers that
   are used at the MAC operate on the fields of the IP header and the
   transport protocol and these include the IP Traffic class, Next
   header field, Masked IP source and destination addresses and,
   Protocol source and destination port ranges.

==> this is probably defined better in 802.16, but not all traffic may have
a traffic class (v4 has DSCP which is similar), you don't define what is
"masked {dst,src} address" (just some kind of prefix part of an address?),
and there may not necessarily be any port ranges involved (non-TCP/UDP
protocols).

Is more precise specification of this required to create interoperable
implementations?  Is it a problem if different hosts make different
classifications for the same kind of traffic?

   Hence the point-to-point link model
   for IPv6 operation over the IP specific part of the Packet CS in
   802.16 is recommended.  A unique IPv6 prefix(es) per link (MS) is
   also recommended.

==> you don't discuss what will happen if these recommendations are not
followed, in fact, the whole document assumes they are adhered to.  Either
this should be discussed or the recommendations should be made stronger
(requirements).

6.3.  Maximum transmission unit in 802.16

[...]  The Max value of the IPv6 MTU for 802.16 is 2038
   bytes and the minimum value of 1280 bytes.  The default MTU for IPv6
   over 802.16 SHOULD be the same as specified in RFC2460 which is 1500
   octets.  RFC2461 defines an MTU option that an AR can advertise to an
   MN.  If an AR advertises an MTU via the RA MTU option, the MN should
   use the MTU from the RA.

==> Should the last sentence use uppercase keywords?
==> However, if the MS is a router, RA is basically ignored in this kind of
context.  Hence, this approach of non-default MTU configuration seems
applicable between host and a router only.

8.1.  Router Solicitation
   [...] Movement detection at the IP layer of an MS
   in many cases is based on receiving periodic router advertisements.

==> yet, in 8.3 you make the period much longer, to be counted in hours.
That's not useful for movement detection, text above should probably be
adjusted.

8.3.  Router lifetime and periodic router advertisements

==> it is not clear if the implications of the design decision to raise the
default advertisement intervals has been adequately understood.  Will this
mean that every single instance of protocols which use too low intervals
will need to be modified?  How do you deal with periodic MLD reports, for
example?  How do you prevent frequent port scanning from waking up the host
every 5 minutes when the router wants to do Neighbor Solicititation for the
address?

 The
   granularity of the GRE tunnel should be on a per MS basis or on a per
   service flow basis (an MS can have multiple service flows, each of
   which are identified uniquely by a service flow ID).

==> So, it's possible to have multiple GRE tunnels between AR and BS.  Yet,
I do not see how different GRE tunnels are multiplexed/demultiplexed.  GRE
header does not support this AFAICS -- you'd need to use different
source/destination IP address pairs, or encode different flows as different
'Protocol type' values (16 bits), but the latter would require
modifications
to GRE processing code at both endpoints of the tunnel.   Therefore I'm not
sure if this approach is workable.

Appendix D.  Maximum transmission unit in WiMAX

   The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets.
   Hence the IPv6 path MTU can be 1500 octets.  However because of the
   overhead of the GRE tunnel used to transport IPv6 packets between the
   BS and AR and the 6 byte MAC header over the air interface, using a
   value of 1500 would result in fragmentation of packets.  It is
   recommended that the default MTU for IPv6 be set to 1400 octets for
   the MS in WiMAX networks.  Note that the 1522 octet specification is
   a WiMAX forum specification and not the size of the SDU that can be
   transmitted over 802.16, which has a higher limit.

==> This brings up multiple problems:

 1) main body said SHOULD use 1500 bytes, yet this recommends 1400.
 2) there is no statement in the document how to treat the appendices,
i.e.,
why thet even exist in this document especially if they contain
contradicting material.
 3) The text above seems technically incorrect.  The key point here is what
is the MTU on the wired link between BS and AR.  If it supports MTUs higher
than 1500 (for example, GE jumboframes, SDH, ATM, whatever), tunneling
could
possibly still be used.

editorial
---------

Abstract

   IEEE Std 802.16 is an air interface specification.  IEEE has
   specified several service specific convergence sublayers (CS) for
   802.16 which are used by upper layer protocols.  The ATM CS and
   Packet CS are the two main service specific convergence sublayers and
   these are a part of the 802.16 MAC which the upper layers interface
   to.  The packet CS is used for transport for all packet-based
   protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet)
   and, IEEE Std 802.1Q (VLAN).  The IP specific part of the Packet CS
   enables transport of IPv6 packets directly over the MAC.  This
   document specifies the addressing and operation of IPv6 over the IPv6
   specific part of the packet CS for hosts served by a network that
   utilizes the IEEE Std 802.16 air interface.  It recommends the
   assignment of a unique prefix (or prefixes) to each host and allows
   the host to use multiple identifiers within that prefix, including
   support for randomly generated identifiers.

==> s/the assignment of/assigning/ ?
==> abstract is a bit on the lengthy side.  Maybe shorten a bit from the
beginning, e.g. leaving ATM CS and some more generic sublayer discussions
out of the abstract?

2.  Introduction

==> the introduction mentions "mobile station/host", yet I think there
is no
restriction that the endpoint be a) mobile (could be a fixed wireless link
as well), and b) a host (could be a router as well).  Maybe some further
clarification here is needed to make it clear that fixed/router scenarios
are also to be addressed by this specification.

==> it might be helpful to have a diagram in section 2, as there are at
least four functional components (AR, BS, link, MS) and at least AR hasn't
been spelled out.  This also seems to include some assumptions about
connecting a host to a router (above).

4.1.  IPv6 encapsulation over the IP CS of the MAC

   The IPv6 payload when carried over the IP specific part of the Packet
   CS is encapsulated by the 6 byte 802.16 MAC header.  [...]

==> "encapsulated by" seems a bit strange.. also, later you use
"encapsulated .. in".

   The IPv6 node requirements RFC RFC4294 [RFC4294] specifies [...]

==> s/ RFC RFC4294//

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Jan 2007 15:29:49 +0200

Hi,

Some thoughts on the substantive points raised by

> the all nodes multicast address, etc.) handled?

I believe there are generic issues such as port scanning that may
be best handled elsewhere. This document should be free to
address the specific IP layer issues, however. (Not commenting
on what the solution is, however, or the lack of a solution for
some of these things. But all-nodes address in the recommended
link scope does not appear to be a problem.)

> clarity why the appendices are there to begin with.

I am getting the sense that removing the Wimax-specific discussion
is the right thing. In addition, your comments regarding GRE
multiplexing should be taken into account in the Wimax work.
Basavaraj works in Wimax Forum, I'm sure he can bring that
issue up there.

> it specified elsewhere?) and some miscellaneous issues.

Specified elsewhere. This needs to be made clearer.

> substantial

Yes.

> this should be discussed or the recommendations should be made stronger

They should be requirements.

> applicable between host and a router only.

This should be made clear in the text -- perhaps with appropriate
warning label that discourages such usage. (If Wimax Forum wants
to do that due to the MTU of the backend tunnels, it would be their
conscious choice.)

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 31 Jan 2007 15:05:27 +0100

Jari Arkko wrote:
> Hi,
> 
> Some thoughts on the substantive points raised by Pekka's review:
[...]
>> It is not clear if traffic classification is adequately specified 
>> (or is it specified elsewhere?) and some miscellaneous issues.
>> 
> 

I think it _may_ be relevant here.  IPv6 has a Traffic Class field with
defined values (see rfc2474 for 6bit DSCP, and rfc2597 for AF Assured
Forwarding values).  802.16 has Service Class service flow encodings
(11.13.4 in 802.16-1004).  The mapping between the two should be
specified here I believe.

Basically one would need to define mappings between DSCPs and 802.16
Service Flow encodings.  Remark the mapping is not straightforward
because DSCP uses 6bit while service field is on 4bit.  But not all
values from 6bit need to be encoded either.

I think 802.16 spec doesn't define these mappings.  Although they do
define filter in the CS that interprets the IPv6 Traffic Class field.

I think we need advice from QoS community on this.

Alex

> 
>> substantial -----------
>> 
>> ==> looking at the other "IPv6 over foo" documents, this document 
>> doesn't specify or mention the following: - link-local address 
>> generation  (exactly as described in RFC2464, I suppose?) - unicast
>>  and multicast address mapping
>> 
>> Maybe these don't require much text but an explicit note might be a
>>  good thing to have.
>> 
> 
> Yes.
> 
>> Hence the point-to-point link model for IPv6 operation over the IP 
>> specific part of the Packet CS in 802.16 is recommended.  A unique 
>> IPv6 prefix(es) per link (MS) is also recommended.
>> 
>> ==> you don't discuss what will happen if these recommendations are
>>  not followed, in fact, the whole document assumes they are adhered
>>  to.  Either this should be discussed or the recommendations should
>>  be made stronger (requirements).
>> 
> 
>> [...]  The Max value of the IPv6 MTU for 802.16 is 2038 bytes and 
>> the minimum value of 1280 bytes.  The default MTU for IPv6 over 
>> 802.16 SHOULD be the same as specified in RFC2460 which is 1500 
>> octets.  RFC2461 defines an MTU option that an AR can advertise to 
>> an MN.  If an AR advertises an MTU via the RA MTU option, the MN 
>> should use the MTU from the RA.
>> 
>> ==> Should the last sentence use uppercase keywords? ==> However, 
>> if the MS is a router, RA is basically ignored in this kind of 
>> context.  Hence, this approach of non-default MTU configuration 
>> seems applicable between host and a router only.
>> 
> 
> warning label that discourages such usage. (If Wimax Forum wants to 
> do that due to the MTU of the backend tunnels, it would be their 
> conscious choice.)
> 
> Jari
> 
> 
> 
> _______________________________________________ 16NG mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/16ng
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Jan 2007 16:16:49 +0200

> define filter in the CS that interprets the IPv6 Traffic Class field.
Anyone who understands in detail what 802.16 classification
does, feel free to jump in here... DJ?

My assumption was that 802.16 defines a classification mechanism
that can look at certain fields from IP packets and determine what
service flow should be used, including all parameters used in the
service flow. If this is not the case then you are right.

Jari

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 1 Feb 2007 00:37:21 +0900

> service flow. If this is not the case then you are right.

Classification is the process by which a MAC SDU (IPv6 packet in our
case) is mapped onto a particular transport connection for
transmission between MAC peers (BS and MS in our case). The mapping
process associates an IPv6 packet with a transport connection and its
CID (Connection Identifier).

Classifiers are matching criteria applied to each packet and consist
of some protocol-specific packet matching criteria such as destination
IP address. If a packet matches the specified packet matching criteria
(i.e. classifier(s)), it is then delivered to the SAP for delivery on
the connection defined by the CID (Connection Identifier).

You may find more detail in 5.2.2 of 802.16. I also put a figure in

http://www.diffeo.com/16ng/fig.gif

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 31 Jan 2007 17:14:15 +0100

JinHyeock Choi wrote:
>>> I think it _may_ be relevant here.  IPv6 has a Traffic Class
>>> field with defined values (see rfc2474 for 6bit DSCP, and rfc2597
>>> for AF Assured Forwarding values).  802.16 has Service Class
>>> service flow encodings (11.13.4 in 802.16-1004).  The mapping
>>> between the two should be specified here I believe.
>>> 
>>> Basically one would need to define mappings between DSCPs and
>>> 802.16 Service Flow encodings.  Remark the mapping is not
>>> straightforward because DSCP uses 6bit while service field is on
>>> 4bit.  But not all values from 6bit need to be encoded either.
>>> 
>>> I think 802.16 spec doesn't define these mappings.  Although they
>>> do define filter in the CS that interprets the IPv6 Traffic Class
>>> field.
>> 
>> Anyone who understands in detail what 802.16 classification does,
>> feel free to jump in here... DJ?
>> 
> of some protocol-specific packet matching criteria such as
> destination IP address. If a packet matches the specified packet
> matching criteria (i.e. classifier(s)), it is then delivered to the
> SAP for delivery on the connection defined by the CID (Connection
> Identifier).
> 

JinHyeock, thanks for clarification.  I think it confirms my
expectations of how 802.16spec intends IPv6CS classifiers to work: by
looking at IPv6 headers.

Assume an IPv6 packet put by the SS's IPv6 stack on the 802.16MAC has
the Traffic Class equal to DSCP AF11 '001010' (rfc2597 - Class1 with Low
Drop Precedence).

_How_ does this convert into a service flow?

More specifically, what is the priority assigned to this service flow?
("traffic priority": sec 11.13.5 of 802.16-2004).  This encoding has
values from 0 to 7 with higher numbers indicating higher priority.  If
not the "traffic priority" value then what are the other service
flow-specific constants that this IPv6 DSCP (diffserv codepoint) 
converts into.

Thanks,

Alex

---

From: "yw_chen" <[email-masked]>
Date: Thu, 1 Feb 2007 00:21:12 +0800

Dear All,

I am Yen-Wen Chen from Dept. of Communication Engineering, National Central 
University, Taiwan. As I know that the classifier in 802.16 is applied to 
match the network layer traffic (e.g. IP packets or IPv6 packets) into MAC 
flows of 802.16. Each MAC flow has a connection ID (CID) and is associated 
with a specific forwarding class (e.g. UGS, rtPS, nrtPS, ertPS, or best 
effort) and QoS-related parameters (e.g. delay time, loss rate, etc.). The 
mapping rules does not specify in the spec. and is decided in accordance 
with different applications. Packets with different IP Headers may be mapped 
to the same CID if those packets are with the same treatment in the link 
layer of 802.16.

Yen-Wen

On Thu, 1 Feb 2007 00:37:21 +0900, JinHyeock Choi wrote
> matching criteria
> (i.e. classifier(s)), it is then delivered to the SAP for delivery 
> on the connection defined by the CID (Connection Identifier).
> 

--
Open WebMail Project (http://openwebmail.org)

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 31 Jan 2007 18:23:00 +0100

Hi yw_chen,

yw_chen wrote:
> Dear All,
> 
> I am Yen-Wen Chen from Dept. of Communication Engineering, National 
> Central University, Taiwan. As I know that the classifier in 802.16 
> is applied to match the network layer traffic (e.g. IP packets or 
> IPv6 packets) into MAC flows of 802.16. Each MAC flow has a 
> connection ID (CID) and is associated with a specific forwarding 
> class (e.g. UGS, rtPS, nrtPS, ertPS, or best effort) and QoS-related 
> parameters (e.g. delay time, loss rate, etc.). The mapping rules does
>  not specify in the spec. and is decided in accordance with different
>  applications.

I believe when 802.16 spec says 'in accordance with different
applications' it means IP is one of those applications.

I think both the 802.16MAC implementation _and_ the IPv6 stack should
respect the same - unwritten - mapping rules.  Otherwise my IPv6 stack
on a vendor's 802.16MAC won't work on another vendor's.

> Packets with different IP Headers may be mapped to the same CID if
> those packets are with the same treatment in the link layer of
> 802.16.

I'm fine with that.

But does IPv6 DSCP AF11 '001010' (rfc2597) map into 'UGS' or into 'Best
Effort' forwarding class (802.16)?  Which one do you like more?  Which
one is implemented?

Alex
PS: 802.16 terms:  UGS - Unsolicited Grant Service
                  rtPS - real-time Polling Services
                 nrtPS - non-real-time Polling Services
                 ertPS - ??

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 31 Jan 2007 21:49:00 -0600

Hi Pekka,

>and/or a router has been adequately considered or whether this is an

The term SS as has been defined and proposed for inclusion in the
problem statement I-D (Ref: PSDOC in the I-D) is:

o Subscriber Station (SS): An end-user equipment that provides
connectivity to the 802.16 networks. It can be either fixed/nomadic
or mobile equipment. In mobile environment, SS represents the
Mobile Subscriber Station (MS) introduced in IEEE 802.16e
specification. 

The email on the terminology is at:
http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html

In the case the MS is a CPE type of device serving hosts attached to
it, then the behavior of the CPE in this I-D is the same as an MS/SS.

>the all nodes multicast address, etc.) handled?

Filtering extra RAs is not an option. The MS expects an RA at
MaxAdvIntervals and filtering them would disrupt MS behavior.

The MS and AR are connected via a PtP link which is created via a
combination of the transport connection over the air interface and a
corresponding GRE tunnel between the BS and AR. Are there specific
issues w.r.t MLD reports etc. on a PtP link that you believe need to
be clarified?
Pinging the all-nodes multicast address is an interesting issue. Doing
so for example on the AR would result in flooding the access network
and causing congestion on the air-interface if you have a large number
of hosts attached to the network. Hence an AR may explicitly prevent
such pinging.  

>clarity why the appendices are there to begin with.

The MTU recommendation in the apendix is specific to WiMAX because of
a profile that has been adopted which is a subset of the 802.16
specification. I dont understand the GRE tunnel multiplexing issue
that you mention.
Note that the appendix is informational only in the context of this
document. The reason why it is useful is because of the fact that
802.16 deployments today is primarily as WiMAX. Hence the appendix
shows the applicability of the spec to a specific realization of a .16
network. 

>it specified elsewhere?) and some miscellaneous issues.

Classification rules are specified in the 802.16 specification.

Yes. 

>Maybe these don't require much text but an explicit note might be a good

Okay. I can add a sentence in the text. But since there is no
variation from the IPv6 specifications for such addresses, I do not
know if it helps in adding such a statement.

>classifications for the same kind of traffic?

The classification rules operate on a set of fields defined in
802.16. Absence of such fields (for example ports in non TCP/UDP
protocols) in a packet are essentially ignored. To quote 802.16 for
the case of port numbers:
"
If this parameter is omitted the protocol destination port is
irrelevant. This parameter is irrelevant for protocols without port
numbers. 
"

Masked src/dest address classification rule is simply a means of specifying
address ranges via a mask.

I can try and clarify this section better and add a reference to the
802.16 spec for further details on the classification rules.

>this should be discussed or the recommendations should be made stronger

Okay... I can make it a requirement.

Yes.

>applicable between host and a router only.

Okay... Do you have any suggestion or text that would help in this
context?

>That's not useful for movement detection, text above should probably be

But if you see the sentence following the above in sec 8.1, I do state
that link-layer triggers can be used to send router solicitations
instead and not rely on periodic RAs. So the sentence when read by
itself is in conflict with Sec 8.3 but not when read with the
following sentences in Sec 8.1.

>will need to be modified?

What specific protocols would you be concerned in this case? I know
MIP6 for example uses a lower interval for RAs for movement
detection. But as I said, movement detection in the case of 802.16 can
be dealt with at the link layer and triggers to indicate such movement
to the IP layer.

> How do you deal with periodic MLD reports, for
>example?  

So what would break if periodic MLD reports are not sent.

>How do you prevent frequent port scanning from waking up the host

It does not make sense to do wake up the host every 5 mins. Is there a
reason for the AR to do NS periodically?
In case a packet for the MS arrives at the AR, paging is used wake up
and establish the link and deliver the packet to the host.

>sure if this approach is workable.

Let me send a separate explanation for this.

> 1) main body said SHOULD use 1500 bytes, yet this recommends 1400.

This recommendation is WiMAX specific and is in the appendix. The
recommendation in the main body is applicable to 802.16 in general.

>why thet even exist in this document especially if they contain

Well... The appendix is informational only. It exists to demonstrate a
realization of a network based on 802.16 air interface. I can add
explicit clarification to this effect.

>than 1500 (for example, GE jumboframes, SDH, ATM, whatever), tunneling

True... But the fact is that for WiMAX, the profile specifies a MAX
SDU of 1522 octets. So the packets on the air-interface cannot be
greater than 1522 bytes. So the existence of links with higher MTU
capability on the link between the BS<->AR does not matter.

>beginning, e.g. leaving ATM CS and some more generic sublayer discussions

Okay... Will attempt.

>are also to be addressed by this specification.

Okay. I can add further text to the definition of MS/SS to include
such hosts.

>connecting a host to a router (above).

Will consider if it would help.

>==> "encapsulated by" seems a bit strange.. also, later you use

I dont know if it is a problem. But I can rephrase. Do you have a
better term?

Yes.

-Raj