Subject: [16NG] Network entry procedure for IPv6 over IP CS

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Dec 2006 19:19:40 +0100

Dear 16ng'ers,

Following the public discussion with Raj, I think modifications are
needed to the IEEE 802.16 network entry procedure, in order to better
support IPv6 stateless autoconf.  Basically, the simplest modif is to
add Interface IDs, or maybe the link-local addresses in Reg
Req/Response.  (for better supporting DHCPv6 I'll look later.)

The generic entry procedure is the following:

1) scan, obtain transmit parms, range,
    negociate capabilities, authorize
2) registration
3) establish IP connectivity
4) time of day, transfer operational parameters,
    set up provisioned connections (qos-enabled).

The detail exchange is in the Post Scriptum .  The two interesting steps
are 2 and 3.  Their details are the following:

BS            SS
----------------
   <- Reg Req
      Reg Resp ->
      RS ->
   <- RA

Basically, the SS and BS don't know where exactly to send their first
RSs and RAs respectively, the dst address field of the IP header.  So I
propose to add the Interface IDs (or maybe the link-local addresses) in
RegReq and RegResp.  This can be achieved in several ways:

1) BS provides its IID in RegResp, SS sends RS to BS, BS learns the
    link-local address of SSfrom that RS, and replies back.
2) The other way around, SS provides its IID.
3) a negotiation way: SS proposes its IID and BS its own.
4) etc.

The IID field (or link-local address) can be encoded as a new type 18
(17 is the last used) in RegReq/RegResp over 64 or 128bit respectively.

What do you think?

Alex
PS:
BS               SS
-------------------
     DL-MAP ->
   UCD and DCD ->
     DL-MAP ->
     UL-MAP ->
   <- RNG-REQ
      RNG-RSP->
   <- SBC-REQ
     SBC-RSP ->
   <- Auth Info
   <- Auth Req
      Auth Rep ->
   <- Key Req
      Key Rep ->
   <- Reg Req
      Reg Rsp ->
  <- DHC DISCOVERY
     DHC OFFER ->
  <- DHC REQUEST
     DHC RESPONSE ->
  <- Time Req
     Time Resp ->
  <-TFTP config file
    TFT CPLT ->
  <- TFT RSP
    DSA REQ ->
   <- DSA RESP

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

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 15 Dec 2006 12:41:13 -0600

I disagree with Alex that changes to the IEEE 802.16 specifications or the
network entry procedures are needed.

-Raj

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Fri, 15 Dec 2006 21:24:55 +0200

Hi,

I agree with Raj. Anyways, I think any these kind of discussions are out of
place in the IETF - especially when there is no problem.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Dec 2006 21:26:55 +0100

Basavaraj Patil wrote:
> I disagree with Alex that changes to the IEEE 802.16 specifications
> or the network entry procedures are needed.

It's easy to disagree Raj, I respect your point of view.

But do you think that (unmodified) 802.16 network entry procedure I've
listed in detail is ok?  Do you think it makes sense to add it to the
draft to make it more clear?

Alex

>>  needed to the IEEE 802.16 network entry procedure, in order to
>> better support IPv6 stateless autoconf.  Basically, the simplest
>> modif is to add Interface IDs, or maybe the link-local addresses in
>> Reg Req/Response.  (for better supporting DHCPv6 I'll look later.)
>> 
>> 1) scan, obtain transmit parms, range, negociate capabilities,
>> authorize 2) registration 3) establish IP connectivity 4) time of
>> day, transfer operational parameters, set up provisioned
>> connections (qos-enabled).
>> 
>> The detail exchange is in the Post Scriptum .  The two interesting
>> steps are 2 and 3.  Their details are the following:
>> 
>> BS            SS ---------------- <- Reg Req Reg Resp -> RS -> <-
>> RA
>> 
>> Basically, the SS and BS don't know where exactly to send their
>> first RSs and RAs respectively, the dst address field of the IP
>> header.  So I propose to add the Interface IDs (or maybe the
>> link-local addresses) in RegReq and RegResp.  This can be achieved
>> in several ways:
>> 
>>  link-local address of SSfrom that RS, and replies back. 2) The
>> other way around, SS provides its IID. 3) a negotiation way: SS
>> proposes its IID and BS its own. 4) etc.
>> 
>> The IID field (or link-local address) can be encoded as a new type
>> 18 (17 is the last used) in RegReq/RegResp over 64 or 128bit
>> respectively.
>> 
>> What do you think?
>> 
>> Alex PS: BS               SS ------------------- DL-MAP -> UCD and
>> DCD -> DL-MAP -> UL-MAP -> <- RNG-REQ RNG-RSP-> <- SBC-REQ SBC-RSP
>> -> <- Auth Info <- Auth Req Auth Rep -> <- Key Req Key Rep -> <-
>> Reg Req Reg Rsp -> <- DHC DISCOVERY DHC OFFER -> <- DHC REQUEST DHC
>> RESPONSE -> <- Time Req Time Resp -> <-TFTP config file TFT CPLT ->
>>  <- TFT RSP DSA REQ -> <- DSA RESP
>> 
>> _______________________________________________ 16NG mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/16ng
> 
>

---

From: Daniel Park <[email-masked]>
Date: Mon, 18 Dec 2006 12:18:28 +0900

Hi Alex, 

[chairs hat-on]

Given the charter of the 16ng working group, the working
group may issue recommendations to IEEE802.16 and WiMAX
aiming at improving support for IP. So, you can make your
recommendation to the relevant technology in conjunction with
the 16ng works. However, we should be very careful to say
modification to the existing standard, particularly IP underneath.
Obviously, it is not scope of the IETF especially newly defining
or modifying 802.16 MAC/PHY technology. Our principal 
objective is to specify the operation of IPv4 and IPv6 OVER 
IEEE 802.16. 

So I'd encourage you to continue your valuable efforts on the 
current approach based on the existing standard. In order words,
I'd recommend you not to continue any specific and in-depth
changes/modifications regarding the relevant standards. 

Otherwise, we will not be able to have any conclusions at all. 
You will contribute your concerns to the relevant SDOs of 
course...:-)

[chairs hat-off]

Thanks your kind understanding in advance.

PS, Alex, you can subscribe IEEE 802.16 list for further 
discussion in terms of 802.16 standard itself. See you in
there if you have more...

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: "Syam Madanapalli" <[email-masked]>
Date: Mon, 18 Dec 2006 09:08:11 +0530

Hi Alex,

With the modification your are suggesting, you will be just avoiding the
DAD for link local address. I think it is OK to do DAD on point-to-point links,
I did not see any thing wrong in this.

The problem that I see is the requirement of IP address for MAC connection
establishment. But this has been solved in WiMAX Forum by defining an
Initial Service Flow (ISF) which does not require an IP address. The initial
RS/RA can be exchanged using this ISF as well as DAD probes and
any response.

Thanks,
Syam

On 12/15/06, Alexandru Petrescu <[email-masked]> wrote:
> e

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Mon, 18 Dec 2006 09:52:10 +0100

Alexandru,

The interface ID, which you are looking for, is coming with the GP CS in
802.16g.
It looks there is good reason for the GP CS in addition the 802.1D
(bridging) support.

Bye
Max

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, December 15, 2006 7:20 PM
To: [email-masked]
Subject: [16NG] Network entry procedure for IPv6 over IP CS

Dear 16ng'ers,

BS            SS
----------------
   <- Reg Req
      Reg Resp ->
      RS ->
   <- RA

What do you think?

Alex
PS:
BS               SS
-------------------
     DL-MAP ->
   UCD and DCD ->
     DL-MAP ->
     UL-MAP ->
   <- RNG-REQ
      RNG-RSP->
   <- SBC-REQ
     SBC-RSP ->
   <- Auth Info
   <- Auth Req
      Auth Rep ->
   <- Key Req
      Key Rep ->
   <- Reg Req
      Reg Rsp ->
  <- DHC DISCOVERY
     DHC OFFER ->
  <- DHC REQUEST
     DHC RESPONSE ->
  <- Time Req
     Time Resp ->
  <-TFTP config file
    TFT CPLT ->
  <- TFT RSP
    DSA REQ ->
   <- DSA RESP

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 18 Dec 2006 11:33:57 +0100

Daniel, thanks for the reply, both as Chair and as member.

Daniel Park wrote:
> Hi Alex,
> 
> [chairs hat-on]
> 
> Given the charter of the 16ng working group, the working group may 
> issue recommendations to IEEE802.16 and WiMAX aiming at improving 
> support for IP. So, you can make your recommendation to the relevant
>  technology in conjunction with the 16ng works. However, we should be
>  very careful to say modification to the existing standard, 
> particularly IP underneath. Obviously, it is not scope of the IETF 
> especially newly defining or modifying 802.16 MAC/PHY technology. Our
>  principal objective is to specify the operation of IPv4 and IPv6 
> OVER IEEE 802.16.
> 
> So I'd encourage you to continue your valuable efforts on the current
>  approach based on the existing standard. In order words, I'd 
> recommend you not to continue any specific and in-depth 
> Otherwise, we will not be able to have any conclusions at all. You 
> will contribute your concerns to the relevant SDOs of course...:-)

Thanks for the recommendation.  I perfectly understand 16ng is chartered
to work on IP_over_ an unmodified link-layer.

I think my suggestion to enhance the link-layer (with a IP-friendlier
exchanges, include IIDs prior to RS/RA) should be addressed to IEEE, not
to IETF.  As all link-layer enhancements should.

I was wondering who is the Liaison person between IETF and IEEE.  Maybe
there is interest to have a common understanding in this WG about what
should the link-layer entry procedure be, and prepare a statement that
could be relayed by the Liaison to IEEE.

> PS, Alex, you can subscribe IEEE 802.16 list for further discussion 
> in terms of 802.16 standard itself. See you in there if you have 
> more...

I'm not sure what are the participation rules in IEEE standards.  For
IETF the process is documented in relevant RFCs.  But I'll subscribe to
the 802.16 list see whether I can post.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 18 Dec 2006 11:56:56 +0100

Syam Madanapalli wrote:
> Hi Alex,
> 
> With the modification your are suggesting, you will be just avoiding
>  the DAD for link local address.

I think yes.

> I think it is OK to do DAD on point-to-point links, I did not see any
>  thing wrong in this.

Mainly yes.

However, there is certainly a gain in not doing DAD, when we know that
only two points are valid on the p2p link.  Save in number of messages, etc.

The thing is whether this is real point-to-point links, or virtual
interfaces.  Does the SS use MAC-derived link-local addresses for those
links, or not.  If it does (seems to be the case) then it will
necessarily share that MAC address among all these virtual interface,
because impossible to reserve a MAC address per-MN, on the BS.  This
makes it a necessity to do DAD on these links.  But they'll probably no
longer be real point-to-point links.

It can be very helpful to know whether the implementation does use one
virtual interface on BS, per SS attaching to it, what link-local address
on that interface - derived from MAC or not.

> The problem that I see is the requirement of IP address for MAC 
> connection establishment. But this has been solved in WiMAX Forum by
>  defining an Initial Service Flow (ISF) which does not require an IP
>  address. The initial RS/RA can be exchanged using this ISF as well
> as DAD probes and any response.

Ok, the WiMax forum has solved this for WiMax users.  Should WiMax forum
suggest their solution to IEEE, the 16ng will see it too.

Thanks,

Alex

> Thanks, Syam
>> Dear 16ng'ers, e Following the public discussion with Raj, I think
>>  modifications are needed to the IEEE 802.16 network entry 
>> procedure, in order to better support IPv6 stateless autoconf. 
>> Basically, the simplest modif is to add Interface IDs, or maybe the
>>  link-local addresses in Reg Req/Response.  (for better supporting
>>  DHCPv6 I'll look later.)
>> 
>>  RESPONSE -> <- Time Req Time Resp -> <-TFTP config file TFT CPLT 
>> -> <- TFT RSP DSA REQ -> <- DSA RESP
>>

---

From: "Syam Madanapalli" <[email-masked]>
Date: Mon, 18 Dec 2006 16:44:42 +0530

> only two points are valid on the p2p link.  Save in number of messages, etc.

This prevents the usage of privacy extensions for SLAAC. So we need
to weigh the benefits.

> longer be real point-to-point links.

A set of CIDs between MS and BS should be treated as p2p link, in case
of separate BS and AR, the tunnel i/f at the AR can be used to identify
the p2p link.

As far as BS is concerned, it should be caring about type of link, it just
deals with the CIDs.

> on that interface - derived from MAC or not.

At any given time, an MS attaches to only on BS and exists only one p2p
link between MS and AR.

> suggest their solution to IEEE, the 16ng will see it too.

I think we are solving the problems for WiMAX Forum, I do not think we have
any other use case for 802.16 at least for now.

Thanks,
Syam

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 18 Dec 2006 20:46:03 +0100

Hi Syam, thanks for reply, snipping some parts I agree with...

Syam Madanapalli wrote:
>>  interfaces.  Does the SS use MAC-derived link-local addresses for 
>> those links, or not.  If it does (seems to be the case) then it 
>> will necessarily share that MAC address among all these virtual 
>> interface, because impossible to reserve a MAC address per-MN, on 
>> the BS.  This makes it a necessity to do DAD on these links.  But 
>> they'll probably no longer be real point-to-point links.
> 
> A set of CIDs between MS and BS should be treated as p2p link, in 
> case of separate BS and AR, the tunnel i/f at the AR can be used to 
> identify the p2p link.

Not sure I get this...

IPv6 RFCs don't use interface names (eg "tun0") in their descriptions.

The tunnel i/f can't be used as identification of a SS, on the AR side.
  The AR should use SS's MAC address, or SS's IP address.  Or otherwise
the tunnel i/f should have a link-layer address, or a link-local
address.  What kind of tunnel do you assume?  Could you  describe the
text one would see when doing 'ifconfig'?

We were saying we can't convert the CIDs into link-layer addresses,
neither into link-local addresses.

We're also saying that the SS is identified by a MAC address, but the BS
identifies the p2p link by CIDs.  ND SLLAO/TLLAO can't work with
unbalanced types of identifying the ends.  We can imagine SLLAO/TLLAO on
the SS, but not on the AR, because AR doesn't have a means to encode
'tunnel i/f' into SLLAO/TLLAO.  We can't imagine TLLAO/SLLAO either on
BS, because no means to encode CIDs on TLLAO/SLLAO.

> As far as BS is concerned, it should be caring about type of link, it
>  just deals with the CIDs.

Yes, but IPv6 stack doesn't know anything about CIDs.  A rfc IPv6
stack's data structures typically knows about IPv6 addresses and about
48bit MAC addresses, and some other documented foo'ish links.

>> It can be very helpful to know whether the implementation does use 
>> one virtual interface on BS, per SS attaching to it, what 
>> link-local address on that interface - derived from MAC or not.
> 
> At any given time, an MS attaches to only on BS and exists only one 
> p2p link between MS and AR.

Ok, this can be expressed by the AR to always advertise itself as a
default router, in RA lifetimes.  This text could go in spec.

>>> connection establishment. But this has been solved in WiMAX Forum
>>>  by defining an Initial Service Flow (ISF) which does not require
>>>  an IP address. The initial RS/RA can be exchanged using this ISF
>>>  as well as DAD probes and any response.
>> 
>> Ok, the WiMax forum has solved this for WiMax users.  Should WiMax 
>> forum suggest their solution to IEEE, the 16ng will see it too.
> 
> I think we are solving the problems for WiMAX Forum, I do not think 
> we have any other use case for 802.16 at least for now.

Ok.

Thanks,

Alex

---

From: "David Johnston" <[email-masked]>
Date: Wed, 20 Dec 2006 19:32:37 -0800

IETF-IEEE 802 Liasion is Bernard.
IETF-IEEE 802.16 Liasion is me.

I'll be at IEEE 802.16 in January and I'm more than happy to put such a
statement to the working group. It's my job. I'll have a few minutes in
the opening session to present on my liaison activities, I'll present
and the group will almost certainly delegate the task of responding the
NetMan task group.

DJ

---

From: "David Johnston" <[email-masked]>
Date: Wed, 20 Dec 2006 20:15:22 -0800

Alex,

I've just gone back and taken a look at this.. I think this discussion
is based on a huge, but easily made misconception.

802.16 has management connections and transport connection. MPDUs on
management connections contain management messages defined by 802.16,
upper layers never see them. Transport connections carry MSDUs to and
from upper layers. These are what upper layers see.

The last 2 items on the network entry list.. "set up provisioned
connections, operational" refer to the setting up of the transport
connections that will carry IP.

So what is 3) establish IP connectivity? How can it be before the
setting up of transport connections that carry IP?

The answer is in 6.3.9.10.. "Establishment of IP connectivity shall be
performed on the SS's Secondary Management Connection".

The reality is that there is a thing called a secondary management
connection (SMC) that may, but doesn't have to be, established on
network entry.

Unlike the Primary, Basic, Ranging and other management connections, the
SMC doesn't carry well defined MAC management messages. It is bolted to
an IP stack. Not the one you are thinking of, but a parallel IP service
dedicated to managing subscriber stations. The things that are defined
that can happen over the SMC are DHCP, 'establish time of day' as per
RFC 868 (see 6.3.9.11) , 'transfer operational parameters' using TFTP to
get a file containing those parameters, SNMP and anything else the
makers of the box chooses. The contents of the configuration file are
defined in clause 9 of 802.16.

6.3.1.1 says "Bearer or data services shall never be transferred on the
Basic, Primary, or Secondary Management connections."

The SMC is a little controversial, and I don't think it should be in the
spec, but the majority of 802.16 disagree with me (or did when I tried
to kill it). 

However the establishment of IP connectivity described in the network
entry in 802.16 has nothing to do with the IP connectivity we are
dealing with in 16ng.

DJ

> Sent: Friday, December 15, 2006 10:20 AM
> To: [email-masked]
steps

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Dec 2006 10:56:12 +0100

David Johnston wrote:
> I was wondering who is the Liaison person between IETF and IEEE. 
> Maybe there is interest to have a common understanding in this WG 
> about what should the link-layer entry procedure be, and prepare a 
> statement that could be relayed by the Liaison to IEEE.
> 
> IETF-IEEE 802 Liasion is Bernard. IETF-IEEE 802.16 Liasion is me.
> 
> I'll be at IEEE 802.16 in January and I'm more than happy to put such
>  a statement to the working group. It's my job. I'll have a few 
> minutes in the opening session to present on my liaison activities, 
> I'll present and the group will almost certainly delegate the task of
>  responding the NetMan task group.

I feel that clarifying the network procedure for the purpose
of being used by the IPv6-over-IPv6CS is something necessary.

The three clarification topics I'm interested in are the following: (1)
clarify how dhcpv6 is used on SS (2) clarify the possible contention
between stateless/full indicator coming from RA or Reg-Resp and (3)
clarify whether InterfaceID should or shouldn't be negotiated during the
network entry procedure (currently it isn't).

Very short 16ng recent exchanges on these topics showed that for (2) we
may need clarification and that for (3) there may not be any need to
negotiate the InterfaceID.

Besides, for the entry procedutre in 802.16 document itself, there may
some aspects that need to be clarified, but not necessarily for 16ng
purposes.  For example, the fact that .16 document uses TFTP right after
DHCP, or the use of Time protocol.  I don't think this has much impact
on 16ng though.

Finally, I can explain in more detail the (1), (2) and (3) issues, if
necessary, on this mailing list.

Thanks,

Alex