Subject: Re: [16ng] Follow up on 16ng WG session

From: "Daniel Park" <[email-masked]>
Date: Sat, 11 Nov 2006 04:10:22 +0900

Ken,

> First, I mentioned a DHCP relay option to identify port in a relay agent.  This is option 82 and this is covered in RFC3046.  This option was used by DSLAMs for the same purpose as proposed here.

[daniel] The 82 option is already applied for the WiMAX architecture.

> Second, I wanted to follow up on why Proxy ARP is not required for the IPv4 CS.  The link layer elements are described below:
>
>                                                 +-------+
>                                                 |       |
>       +-----+               +-----+             |       |
>       | SS  |---------------| BS  |-------------|  AR   |
>       +-----+               +-----+             |       |
>                                                 |       |
>                                                 +-------+
>
>      +--------+      +-------------------+      +-------+
>      |   IP   |      |         IP        |      |  IP   |
>      +--------+      +--------+--+-------+      +-------+
>      | 802.16 | ---> | 802.16 |  |  GRE  |      |  GRE  |
>      +--------+      +--------+  +-------+      +-------+
>                                  |  PHY  | ---> |  PHY  |
>                                  +-------+      +-------+
>
> Each SS is represented as a single unnumbered p2p link at the AR.  The SS has only it IP address and a default route pointing to the AR.  Since there is no subnet provisioned against the SS's IP interface, it will never ARP since there is no possibility of an SS sharing this link.  All communication must be directed through the AR.  As such, the AR has no need for Proxy ARP.

[daniel] So far, that's correct. What I tried to raise in the room is
to ellaborate on the Proxy ARP clearer than now.

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Tue Nov 14 04:36:56 2006
Date: Tue, 14 Nov 2006 03:57:25 +0900
From: "Daniel Park" <[email-masked]>
To: [email-masked]
Subject: [16ng] IETF67 - Minutes - Preliminary

Special thanks to DJ and Alex for their help.

http://www3.ietf.org/proceedings/06nov/minutes/16ng.txt

Should you find any missing or unclear parts in the minutes, please
let me know that.

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Mon Nov 20 17:18:11 2006
Date: Mon, 20 Nov 2006 13:08:41 +0530
From: "Syam Madanapalli" <[email-masked]>
To: "Jari Arkko" <[email-masked]>
Subject: Re: [16ng] review of draft-ietf-16ng-ipv6-link-model-analysis
cc: [email-masked]

Hello Jari,

Sorry for the delayed response.

All of your comments are valid, which will be
addressed while revising the document.

Thanks for reviewing the draft.
-Syam

On 11/8/06, Jari Arkko <[email-masked]> wrote:
> I reviewed this draft. Overall, I think it
> is in good enough shape and we should
> just ship it and focus on other documents.
> A few comments below, however:
> > 3.1.4.2.  On-link Multicast Support
> >
> >    No native on-link multicast is possible with this method.  However
> >    the multicast can be supported with support of AR performing MLD
> >    snooping(?).
> Multicast support requires the backend system that handles
> that. MLD snooping is merely about optimizing that process,
> not about implementing multicast support.
>
> >    This link model does not require any implementation changes to the
> >    host side.  However the hosts are required to perform duplicate
> >    address detection for all addresses even if the host is reusing the
> >    interface identifier.
> Maybe "requires no other implementation changes, except that..."
>
> > 3.2.4.  Applicability
> >
> >    In enterprise networks, shared services including printers, fax
> >    machines, and other such on-line services are often available in on
> >    the local link.  These services are typically discovered using some
> >    kind of link local service discovery protocol.  The unique prefix per
> >    MS model is not appropriate for these kinds of deployments, since it
> >    is not possible to have shared link services in the ASN.
> This is true, but I'm also missing the reverse argument
> for the shared model. If I'm subscribing to a service
> that covers San Diego with a shared link, I do not wish
> to discover other random people's printers, nor do I
> appreciate them discovering mine.
> > 3.3.  Ethernet Like Link Model
> Based on Dave's presentation, I was expecting to find
> something about MLD in this section, but it was not
> discussed.
> >    And SeND should be used to secure the neighbor discovery procedures.
> I don't think it is the place of this document to
> recommend that. Its a fairly hard requirement
> that we don't design our links so that SEND cannot
> be used. But the use is up to the individuals who
> deploy these systems. Unless, of course, there's
> a particular reason why securing ND is particularly
> important in 802.16 networks.
>
> --Jari
>
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>
>From [email-masked] Fri Dec  1 04:59:22 2006
Date: Thu, 30 Nov 2006 13:18:17 -0600
From: Basavaraj Patil <[email-masked]>
To: ext Jari Arkko <[email-masked]>, <[email-masked]>
cc: ext Behcet Sarikaya <[email-masked]>
cc: Prakash Iyer <[email-masked]>
Subject: [16ng] Re: some comments on draft-ietf-16ng-ipv6-over-ipv6cs-01.txt

Jari,

Responses to your comments inline:

On 11/7/06 10:14 AM, "ext Jari Arkko" <[email-masked]> wrote:

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

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

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

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

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.

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

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

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

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

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

>> Usually a link is bounded by routers
>>    that decrement TTL.
> Usually?

Typo.

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

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

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

Okay.

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

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

Yes.

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

Ok.

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

Ok.

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

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

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

Ok.

Thx for the comments.

-Raj
> --Jari