Subject: Re: [16ng] WGLC : draft-ietf-16ng-ipv6-over-ipv6cs-01

From: Basavaraj Patil <[email-masked]>
Date: Fri, 27 Oct 2006 12:42:20 -0500

Daniel,

Comments inline:

>Raj, 
>
>Before jumping in the details, please let me allow to
>flash out several points among the 16ng deliverables.
>
>[1] Terms inconsistency:
>
>Among the three deliverables, I am really confusing the definition
>of each term duplicated. E.g., AR, MS, Transport Connection, etc..
>Those kinds of terms MUST be alligned in a document, then others
>will refer to that simply. I stick to the PS document to take common
>terms in the 16ng space, and each document will have its own
>specific terms only. (Remind: Junghoon and Syam)

Question: Would it be better to simply reference the PS documents
w.r.t the common terms?

I agree with you that consistency of the terms is essential. So
if we go with that approach, I see that the term MS is not in the
terminology section of the PS doc. The term SS and MS are used
interchangeably in 802.16 and WiMAX. So if we could enhance the PS
document with the description of MS that is in this document, then we
do not need to have it in this document as well.

I also do not see the term AR in the PS doc. So either we add it in
the PS doc or leave it here since it is used extensively within the
scope of this doc.

And as far as the definition of the transport connection goes, I think
the explanation in this I-D is more clear than the one in the PS
doc. Again, should I request that the PS doc revise the definition?

>
>[2] In draft-ietf-16ng-ipv6-over-ipv6cs-01,
>
>Section 6.1. IPv6 link in 802.16 said:
>
>"For 802.16 network, following the 3GPP precedent [RFC3314],
>point-to-point link model is recommended."
>
>I am not sure why you are not leaning to the draft-ietf-16ng-ipv6
>-link-model-analysis-00 as a reference model of IPv6 link
>at least Section 3.2. Point-to-point Link Model. My preference
>is to use the 16ng DT's deliverable as a reference of IPv6CS
>document. 

I agree with your statement. The link-model-analysis I-D is indeed the
driver for choosing the PtP link model and I will modify this
accordingly and reference it instead of RFC3314.

> 
> 
>Further details on the WGLC will be forthcoming.
>

Comments appreciated.

-Raj

>Thanks your time and considerations.
>
>Daniel

---

From: "Soohong Daniel Park" <[email-masked]>
Date: Sat, 28 Oct 2006 11:43:31 +0900

Raj,

> do not need to have it in this document as well.

That's what I pointed out, yes, PS will take these terms.

> the PS doc or leave it here since it is used extensively within the

Agreed, these kinds of terms should be in-scope of this document.

> doc. Again, should I request that the PS doc revise the definition?

Yes, I will end up to the revision following the concerned.

> accordingly and reference it instead of RFC3314.

Thanks your time and consideration.

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Mon Oct 30 15:30:17 2006
Date: Mon, 30 Oct 2006 14:04:31 +0900
From: Soohong Daniel Park <[email-masked]>
Subject: Re: [16ng] WGLC : draft-ietf-16ng-ps-goals-00
To: wenson <[email-masked]>
cc: [email-masked]

Wenson, 

> What i concern is whether point to point  link model 
> (details in draft-ietf-16ng-ipv6-link-model-analysis-00)can 
> be implemented based on IP over 802.16 with IP CS, while 
> Ether like link model is implement mostly based on IP over 
> 802.16 with Ethernet CS? 

Yes,

> Another point is Ethernet CS can be introduced to support 
> multcast and broadcast capability, but what the real purpose 
> of introducing Ethernet layer is? I want to know the motivation 
> to introduce Ethernet CS?

I guess you can see some of relevant answers in;
draft-riegel-16ng-ip-over-eth-over-80216-01.txt.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Thu Nov  2 06:08:43 2006
Content-class: urn:content-classes:message
Subject: RE: [16ng] WGLC : draft-ietf-16ng-ps-goals-00
Date: Wed, 1 Nov 2006 20:42:53 +0100
From: "Riegel, Maximilian" <[email-masked]>
To: "wenson" <[email-masked]>
cc: [email-masked]

There are a couple of reasons to consider ETH going over the 802.16
radio interface:
- Wireless DSL
- Ethernet E2E, e.g. for providing VLAN services over 802.16
- multiple hosts behind a CPE
People are considering these scenarios mostly as stationary deployments.

Bye
Max

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of wenson
Sent: Wednesday, October 25, 2006 11:05 AM
To: Soohong Daniel Park
Cc: [email-masked]
Subject: Re: [16ng] WGLC : draft-ietf-16ng-ps-goals-00

What i concern is whether point to point  link model (details in
draft-ietf-16ng-ipv6-link-model-analysis-00)can be implemented based on
IP over 802.16 with IP CS, while Ether like link model 
is implement mostly based on IP over 802.16 with Ethernet CS?
Another point is 
Ethernet CS can be introduced to support multcast and broadcast
capability, but what the real purpose of introducing Ethernet layer is?
I want to know the motivation to introduce Ethernet CS?
 
may i ask you to confirm this?
3x!
----- Original Message ----- 
From: "Soohong Daniel Park" <[email-masked]>
To: "wenson" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 25, 2006 3:37 PM
Subject: Re: [16ng] WGLC : draft-ietf-16ng-ps-goals-00

> Wenson,
> 
>> Since there are two cases to be considered, i.e.,IP over 802.16 with
IP CS and IP over 802.16 with Ethernet CS, the question is:
>> what is the essential difference between these two cases?
>> It seems not clear in demonstrating approach to implement these two
cases in different scenarios.
> 
> Could you please elaborate on the question more ? The most difference
> between them is whether it has a Ethernet functionality or not. When
> implementing IPCS, you don't need any Ethernet funtionalities on the
> stack. Is that your concern ?
> 
> -- 
> 
> 
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
>
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 02 Nov 2006 14:26:02 +0900

Folks,

Here is a common set of the 16ng terms to be included
in the draft-ietf-16ng-ps-goals. For further terms that are 
specific to others document, they can be in that document. 

Any comments are highly welcome. If I am missing anything
that might be included in this common set, please let me know that. 

So far, thanks Raj for his good comments and feedbacks on that.

===================[BEGIN]====================

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. 

o Base Station (BS): A generalized equipment sets providing 
connectivity, management, and control between the subscriber 
station and the 802.16 networks.

o Access Router (AR): An entity that performs an IP routing function 
to provide IP connectivity for subscriber station (SS or MS).

o IP Subnet: Topological area that uses the same IP address prefix
where that prefix is not further subdivided except into individual
addresses as specifed from [I-D.thaler-intarea-multilink-subnet-issues].
  
o  Link: Topological area bounded by routers which decrement the
IPv4 TTL or IPv6 Hop Limit when forwarding the packet as specifed
from [I-D.thaler-intarea-multilink-subnet-issues]. In case of IPv6
link model, refer to the [draft-ietf-16ng-ipv6-link-model-analysis].
 
o Transport Connection: The MAC layer connection in 802.16 between 
a SS(MS) and BS with a specific QoS attributes. Several types of 
connections are defined and these include broadcast, unicast and multicast. 
Each transport connection is uniquely identified by a 16-bit connection 
identifier (CID). A transport connection is an unique connection intended 
for user traffic. The scope of the transport connection is between the 
SS(MS) and the BS.

o Dormant mode: A state in which a subscriber station, especially mobile 
station, restricts its ability to receive normal IP traffic by reducing monitoring 
of radio channels. This allows the mobile station to save power and reduces
signaling load on the 802.16 network. In the dormant mode, the mobile 
station is only listening at scheduled intervals to the paging channel. 
The 802.16 network (e.g. Access Router) maintains state about a mobile 
station which has transitioned to dormant mode and can page it when needed.

o Connection Identifier (CID): A 16-bit value that identifies a connection to 
equivalent peers in the 802.16 MAC of the SS(MS) and BS.

===================[END]====================

>From [email-masked] Thu Nov  2 16:13:20 2006
Date: Thu, 02 Nov 2006 14:47:21 +0900
From: Soohong Daniel Park <[email-masked]>
To: [email-masked]
Subject: [16ng] WGLC Status: draft-ietf-16ng-ps-goals &
 draft-ietf-16ng-ipv6-link-model-analysis

Folks, 

[chair hat-on]

A couple of deliverables have gone through 2 weeks WGLC.

o draft-ietf-16ng-ps-goals: expired on October 31

o draft-ietf-16ng-ipv6-link-model-analysis: expired on October 26

As shown in our agenda, the goal of those deliverables in the
67-IETF are ready for the IESG. For that, obviously we need 
more comments and feedbacks on both.

REMIND: lack of discussion does not represent positive support.
If there is no expression of support for moving the document
forward during the WGLC, the document WILL NOT BE ADVANCED
to the IESG. So, please respond to these WGLC although our 
official WGLC expired. If you tend to accept those documents to
be advanced without change, please respond with a simple
acknowledgement on the list, so that support for the document
can be assessed.

Thanks in advance and see you in San Diego.

[chair hat-off]

>From [email-masked] Thu Nov  2 18:38:56 2006
Date: Thu, 2 Nov 2006 13:43:04 +0530
From: "Syam Madanapalli" <[email-masked]>
To: "Gangaram Vihang-A20783" <[email-masked]>
cc: [email-masked]
cc: Arulselvan Naveen-FNBP34 <[email-masked]>
cc: Suryanarayanan Radhakrishnan-jtcn68 <[email-masked]>
Subject: [16ng] Re: comments on
	draft-ietf-16ng-ipv6-link-model-analysis-00.txt

Hi Vihang,

On 11/2/06, Gangaram Vihang-A20783 <[email-masked]> wrote:
> Syam,
> Based on the draft on IPV6 link models, the following pros and cons seem
> apparent
> Unique prefix for every MS
> 1. DAD becomes trivial
> 2. Privacy addresses
> 3. No local multicast
> Shared prefix model
> 1. DAD/ relay DAD needed with stateless address configuration. This in
> turn, consumes bandwidth
> 2. Privacy addresses (eg. laptop users) need to be managed separately
> 3. Bridging functionality in BS or ALM-like overlay may provide
> link-local multicast support, thereby reducing the burden on AR.
>
> But does this mean that for unique prefix model ETH CS becomes essential
> since PPP can be supported by ETH CS? Option 3 in section 3.2 is still
> bit vague and could you provide some more information on it ?

Section 3.2 is essentially meant for IPv6 CS and if we want to use PPP
to emulate p2p link over 802.16, it is not possible as no PPP CS defined.
The simplest way to abstract the p2p link for 802.16 is to make a set of
connection from the MS to BS as a single IP link. Once you do this
you do not need any other p2p protocols between IP and 802.16. For more
information see
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-01.txt

>
> We think that a Service-based link model may be appropriate. For
> instance,
> 1. Home networks: Less need of local multicast; more likely plug and
> play users
> Adopt a Per-MS prefix model, address autoconfiguration
> 2. Enterprise networks: shared services such as fax, printer; relatively
> low user mobility
> Adopt a Shared prefix model with stateful address allocation.
> But no one is showing interest in shared prefix model so does that imply
> that a there are no takers for deployment in enterprise network ?

Shared prefix model is not completely ruled out, however we need
good use cases that outweigh its inherent drawbacks.

Anyways, I would like to know how the enterprises may use the WiMAX services
if you have any information. For example, will all of the users (as
individuals) in an
enterprise connects to a base station? If yes then it may be difficult
to place an
enterprise into a separate subnet in the shared prefix model.

It may be most likely that in the both scenarios you mentioned, there would be
a gateway terminating WiMAX with a prefix delegation for the network behind
the gateway.

I think, the shared prefix model may be useful if the gateway in turn supports
a local 802.16 interface (i.e. gateway supporting 802.16 on both sides) for
connecting all of its local devices.

- Syam

>
> Thanks
> Vihang
>
>From [email-masked] Fri Nov  3 11:41:09 2006
Date: Thu, 02 Nov 2006 18:15:05 -0700
From: xiayangsong 24512 <[email-masked]>
To: [email-masked]
Priority: normal
cc: [email-masked]
Subject: [16ng] comments about draft-ietf-16ng-ipv6-over-ipv6cs-01.txt

Hi Raj

 1 in the section "6.3.1. Maximum transmission unit in WiMAX"

  suggestion for improvement, please add this text:
    section 4.6.4 of RFC2461 defines a MTU option that an AR
    can advertise to an MN. If an AR advertises an MTU through RA MTU option,
    the MN should use the MTU, otherwise, the MN use default MTU.

  2 in the section "7. IPv6 prefix assignment"
  "The prefixes are advertised with the on-link (L-bit)
  flag set to facilitate Detecting Network Attachment
  (DNA) operation [RFC4135]."

  Problem:
      Reference is not proper, that is, RFC4135 does not
      describe on-link(L-bit) operation.
  suggestion:
      check the reference and give the correct reference
 
 3 in the section "7. IPv6 prefix assignment"

  Problem:
      the current text does not explain where the prefix comes from?
  suggestion for improvement, please add this text:
      AR can request prefixes from a DHCP server using prefix
      option defined in RFC3633.

BR
Frank Xia

---

From: "Soohong Daniel Park" <[email-masked]>
Date: Sat, 4 Nov 2006 11:21:42 +0900

> Suggestion to rephrase base station as follows:
>
> Base station (BS): The Base Station (BS) is a logical entity that embodies a
>                   full instance of the 802.16d/e MAC and PHY in compliance
>                   with the IEEE 802.16 suite of applicable standards.  It
>                   provides the layer 1/2 connectivity between the network
>                   and the MS.
>
> Of course the above definition of base station is specific to an 802.16d/e
> BS and not a generic base station. However in the context of a document that
> is specific to 802.16d/e, it makes sense to specify what the base-station
> refers to.

In fact, I was trying to avoid taking any 16d/e/... specific terms in
here. I am afraid how to deal with 16 extension later (e.g.,
16j/k/m/...). Is there any concern ?

<snip>

> In .16 there is no concept of a paging channel. So the above may cause
> confusion. The DL-MAP contains the page for an MS. Basically the MS in idle
> mode scans periodically for the DL broadcast paging and thus is able to save
> power. I am not sure what you mean when you say it reduces signaling load
> above.

The dormant mode above was just from the
draft-ietf-16ng-ipv6-link-model-analysis. While mentioning the dormant
mode in 16 networks, paging is also illustrated together. But, I am
not sure whether or not we would have paging term in the common set of
16ng terms. For more general, I'd rephrase here.

[CHANGE TO]

Dormant mode: A state in which a SS(MS) restricts its ability to
receive normal IP traffic by reducing monitoring of radio channels.
Especially, this allows the MS to save power. The 802.16 network (e.g.
Access Router) maintains state about the MS which has transitioned to
dormant mode and can page it when needed.

> You may also want to add that connections are unidirectional in nature. For
> bidirectional communication, a connection pair is created and the same value
> assigned for the UL and DL connection.

Do we need elaborate on the CID more ?

-- 

>From [email-masked] Tue Nov  7 10:57:21 2006
Date: Sun, 05 Nov 2006 03:28:27 +0200
From: Jari Arkko <[email-masked]>
To: [email-masked]
cc: Bernard Aboba <[email-masked]>
Subject: [16ng] IAB multiple encapsulations document and discussion in
	int-area

In the Internet Area Open Meeting on Monday,
Bernard Aboba will talk talk about multiple
encapsulations and their effects. The presentation
is available here:

  http://www3.ietf.org/proceedings/06nov/slides/intarea-0.ppt

It would be useful if 16ng folks were present and
could participate in the discussion. Bernard also
had a few questions on his slides, it would be great
if you had the answers.

--Jari

---

From: "Soohong Daniel Park" <[email-masked]>
Date: Mon, 6 Nov 2006 09:38:35 +0900

Raj,

> Well maybe you can just say 802.16 or 802.16 [d/e/...] which would cover
> future revisions of .16. But instead of worrying about the evolution of .16,
> we can take a snapshot of what a BS is as it is understodod today and which
> is relevant to .16d/e.

That makes sense to me at this stage. Ok, let's move it on unless any
explicit arguments appear on the list.

> Well.. Adding the additional two sentences would make the concept of CID
> clearer.

[CHANGE TO]

o Connection Identifier (CID):  A 16-bit value that identifies a
connection to equivalent peers in the 802.16 MAC of the SS(MS) and BS.
The connections are unidirectional in nature. For bidirectional
communication, the connection pair is created and the same value
assigned for the UL (Up Link) and DL (Down Link) connection.

-- 

>From [email-masked] Wed Nov  8 01:30:46 2006
Date: Wed, 8 Nov 2006 00:52:12 +0900
From: "Soohong Daniel Park" <[email-masked]>
To: [email-masked]
Subject: [16ng] Meeting materials - uploaded

For your convenience.

I've uploaded all material to be presented in the 16ng session. Please
refer to the link:

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67

-- 

>From [email-masked] Wed Nov  8 01:53:19 2006
Date: Tue, 07 Nov 2006 08:14:39 -0800
From: Jari Arkko <[email-masked]>
To: [email-masked], Basavaraj Patil <[email-masked]>
Subject: [16ng] some comments on draft-ietf-16ng-ipv6-over-ipv6cs-01.txt

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

---

From: Daniel Park <[email-masked]>
Date: Mon, 04 Dec 2006 21:22:07 +0900

Let's start this thread again.

First, we should elaborate what terms (either 
IPv4CS/IPv6CS or Packet CS) would be workable
within the 16ng. Otherwise, I don't see any trouble to 
add the 16ng terms described below. 

Given the P80280216e_D12, we should use 
these terms like below:

Packet, IPv4
Packet, IPv6
Packet, 802.3/Ethernet

Instead, the 16ng uses:

IPv4CS
IPv6CS
EthernetCS

Strictly speaking, IPv4CS/IPv6CS are not precise expression, 
but I don't see any trouble to use those terms. It seems most
same meaning...BUT, I'd like to listen 16ng folks opinion first.

What about defining the 16ng terms (IPv4/IPv6/EthernetCS)
in accordance with 16 specification to be used for our 
deliverables.  

Comments ?

----- Original Message ----- 
From: "Soohong Daniel Park" <[email-masked]>
To: "Basavaraj Patil" <[email-masked]>
Cc: "ext Soohong Daniel Park" <[email-masked]>; <[email-masked]>; "Junghoon Jee" <[email-masked]>; "Madanapalli, Syam" <[email-masked]>
Sent: Monday, November 06, 2006 9:38 AM
Subject: Re: [16ng] Re: Common set of the 16ng terminologies

>From [email-masked] Mon Dec  4 23:17:31 2006
Date: Mon, 04 Dec 2006 14:32:08 +0100
From: Alexandru Petrescu <[email-masked]>
To: Daniel Park <[email-masked]>
Subject: Re: [16ng] Re: Common set of the 16ng terminologies (IPv4CS/IPv6CS
 or Packet CS)
cc: [email-masked]
cc: [email-masked]

Hi Daniel, I have some oppinions, some may not be fully knowledgeable,

Daniel Park wrote:
> Let's start this thread again.
> 
> First, we should elaborate what terms (either IPv4CS/IPv6CS or Packet
>  CS) would be workable within the 16ng. Otherwise, I don't see any 
> trouble to add the 16ng terms described below.
> 
> Given the P80280216e_D12, we should use these terms like below:
> 
> Packet, IPv4 Packet, IPv6 Packet, 802.3/Ethernet
> 
> Instead, the 16ng uses:
> 
> IPv4CS IPv6CS EthernetCS
> 
> Strictly speaking, IPv4CS/IPv6CS are not precise expression, but I 
> don't see any trouble to use those terms. It seems most same 
> meaning...BUT, I'd like to listen 16ng folks opinion first.

An IEEE CS seems to me to be a filtering mechanism such as to do IP
header compression (remove header before sending, memorize header, send;
receive, match in table, rebuild header).  Since IP headers vary between
IPv4 and IPv6, and since 802.3 MAC header is different again, I believe
the speaking became IPv4 CS, IPv6 CS, ETH CS.  I think CS's goal is only
this header compression, nothing else.  I may be wrong though.

I think I would be interested in an intermediary layer, between
802.16e connection-oriented and 802.3 MAC.  This layer's goals would be
to make the connection-oriented layer look like a 802.3 MAC, when looked
at from the IP stack.  For example, it would map the DL CID to sender's
MAC address, and UL CID to receiver's MAC address; it would duplicate a
packet sent to 33:33:0:0:0:1 (all-nodes MAC) to all connections up at
that interface.  It would transform a MLD JOIN into starting some
connections.  It would assign eg 0x86de as IPv6 Type within the MAC header.

I am not sure I know whether such intermediary layer exists within IEEE,
or whether it is about to be designed.  Or whether it will be called CS
or something else.  Or whether an IEEE CS already does that.

If not, then it will probably be designed, but most certainly not within
the IETF.  This is not core IP work, it is link-layer design.  Probably
within this group it is possible to come up with 'goals' for such an
intermediary layer.  List what an IPv6 stack would like to have as
behaviour beneath it.  One such behaviour would be to require all nodes
under same BS receive a NA sent by one node to all-nodes MAC address.

> What about defining the 16ng terms (IPv4/IPv6/EthernetCS) in 
> accordance with 16 specification to be used for our deliverables.
> 
> Comments ?

I agree clarifying the terminology is needed.  If you suggest to call
them IPv4 CS, IPv6 CS and ETH CS within this group I agree to follow
this terminology and support it.  I am wondering though how will it be
defined.  For example:

"16ng IPv4 CS is IEEE Packet IPv4 CS"?  or
"16ng IPv4 CS is a ROHC working with IPv4"? or
"16ng IPv4 CS is a layer doing this and that, and it works so and so,
                    with full detail"

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 04 Dec 2006 15:13:31 -0600

Daniel,

I think it is best to use the same terms that are specified by IEEE 802.16.
Otherwise we will end up with a consistency issue in the long run.

Currently the 802.16 spec specifies only two CS' (if we do not worry about
GPCS for the time being), ATM and Packet.
The ATM and Packet CS are refered to as being "Service specific CS" .

In the context of Packet CS (which states that it is designed for
transporting IP (v4/6), 802.3 and 802.1Q), the IEEE spec refers to each of
these packet types as:
1. IEEE Std 802.3/Ethernet specific part
2. IEEE Std 802.1Q-1998 virtual local area network (VLAN) specific part
3. IP specific part

They also refer to the PDU formats as :
1. IEEE Std 802.3/Ethernet CS PDU
2. IEEE Std 802.1Q-1998 VLAN CS PDU
3. IP CS PDU  

So there is a semi-acknowledgment of an 802.3CS, 802.1QCS and IPCS as being
a part of the Packet CS.

So my suggestion is that we reference these terms in 16NG as stated in .16
specs.
Hence use the terms:
1. IEEE Std 802.3/Ethernet specific part of the packet CS  packet CS
2. IEEE Std 802.1Q-1998 virtual local area network (VLAN) specific part of
the packet CS
3. IP specific part of the packet CS
Interchangeably with:
802.3CS of the packet CS, 802.1QCS of the packet CS and, IPCS of the packet
CS.

-Raj

On 12/4/06 6:22 AM, "ext Daniel Park" <[email-masked]> wrote:

> Cc: "ext Soohong Daniel Park" <[email-masked]>;
> <[email-masked]>; "Junghoon Jee" <[email-masked]>; "Madanapalli,
> Syam" <[email-masked]>
>>>>>> connection
>>>>>> to

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Dec 2006 14:27:12 +0100

> 802.3CS of the packet CS, 802.1QCS of the packet CS and, IPCS of the packet

Makes sense. I'm inclined to further reduce the length of these terms,
because there seem to be an easiness to talk in short terms like IPCS,
etc. So maybe "DOT3 CS", "DOT1QCS" and "IPCS" would make sense as
16ng abbreviations; expanded as necessary by the terminology 
definitions. Just a suggestion.

Alex

---

From: Daniel Park <[email-masked]>
Date: Wed, 06 Dec 2006 16:16:07 +0900

Raj, 

In fact, I think we are saying the same meaning.
It seems a bit different expression though. I don't
think it is a critical aspect from the 16ng perspective 
and 802.16 Std.

Catching up with your suggestion:
 
802.3CS of the packet CS
802.1QCS of the packet CS
IPCS of the packet CS

It is modified terms from the 802.16 Std too. Isn't it ?
It seems a bit complex and long terms to be used for
our efficient discussion as well as 16ng deliverables in 
my thought.

Slightly trimming:

o EthernetCS: It means 802.3/Ethernet CS specific part of
the Packet CS defined in 802.16 STD.

o 802.1QCS: It means 802.1Q (VLAN) specific part of
the Packet CS defined in 802.16 STD.

o IPv4CS: It means IPv4 specific part of the Packet CS
defined in 802.16 STD.

o IPv6CS: It means IPv6 specific part of the Packet CS
defined in 802.16 STD.

That's my suggestion...:-)

>From [email-masked] Wed Dec  6 22:42:20 2006
Date: Wed, 06 Dec 2006 13:59:35 +0100
From: Alexandru Petrescu <[email-masked]>
To: David Johnston <[email-masked]>
cc: [email-masked]
Subject: [16ng] Re: 802.16g GPCS?

David Johnston wrote:
> That TLV is a [145/146].x TLV used in the connection establishment
> management messages. It is not a per packet value. It is a semi-static
> description of a unicast flow.
> 
> I am far from sure that the use of ethertype in GPCS is correct.
> Ethertypes are carried in every packet to enable protocol multiplexing
> as per 802.2. If GPCS is carrying 802 traffic, the ethertype must be
> carried per packet. The two alternatives in common use are:
> 
> * Ethernet approach - set aside a fixed two byte field in the packet
> header
> * Generic 802 approach , including 802.11 - Start the packet with a SNAP
> header.

I'm sorry, when an IP stack puts a packet on an 802.11 interface there's
a MAC header, before the IP header. The IP stack does not add a SNAP 
header. The driver may. I am interested in 802.16 acting the same as 
802.11, in this respect. Whether that is GPCS or other CS - to clarify.

> There will be comments by me on the initial sponsor ballot on this
> matter.
> 
> The title of 802.16 is perhaps a little misleading. It could better be
> called "Sorting out the interfaces". This is my fault. I chaired the
> study group that set the PAR (~= charter) for 802.16g.

Thanks for clarification.

> This probably isn't the place to discuss this, but I'll go ahead anyway
> since it affects ipv6 encoding. I think the GPCS_PROTOCOL_TYPE TLV in
> 802.16g should not be an ethertype. It should be one level up and
> describe if the payload is one that is 802 (hence carrying an ethertype
> by some means specified in the GPCS text) or something else (ATM, RS232,
> damp string etc.). It is unwise to have a connection descriptor
> mandating what protocol is above, unless it includes an entry for "I
> don't care".

I think I agree, it makes sense. I am not trying to make suggestions
about how the GPCS should work, or be implemented. I am suggesting about
what interface it should present to the IP stack. I only have rough
knowledge of CS inner workings, but I think it is clear what an IP stack
would like it to interface to.

Alex

> 802.16g is a work in progress, so there are plenty of issues to iron out
> yet.
> 
> DJ
> 
> 
> 
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 7:38 AM
> To: Alexandru Petrescu
> Cc: David Johnston; [email-masked]
> Subject: Re: 802.16g GPCS?
> 
> Sorry I've found the 802.16g D6 via other url.
> 
> Reading GPCS goals is very encouraging to my expectations of a MAC 
> working ok with an IPv6 stack.
> 
> There are however unknowns, either due to my lack of understanding 
> 802.16, or other.
> 
> For example, its section 5.3 "GPCS" bullet 3 mentions
> "With GPCS, the upper layer protocol that is immediatedly above the
>   802.16 GPCS is identified by a TLV parameter, GPCS protocol type, as
>   defined in 11.13.19.3.3.20."
> 
> An IPv6 Type field in a MAC header is precisely 0x86DD, it is not 
> encoded as TLV (type-length value) but as a fixed two-byte field (there 
> is no field type and no field length).
> 
> The section 11.13.19.3.3.20 is absent in the document, so one may think 
> that is a nit to correct.  The closest section to it is 11.13.19.5 GPCS 
> CS encodings, which correctly states a fixed 2-byte field, EtherType 
> (implicitely 0x86DD).
> 
> Alex
> 
> Alexandru Petrescu wrote:
>> David Johnston wrote:
>> [snip]
>>> The IEEE 802.16 WG is working on a CS called the GPCS (Generic Packet
>>> Convergence Sublayer) as part of 802.16g.
>> On this particular topic...
>>
>> I'm trying to look at the 802.16g document but server says "Sorry, but
> 
>> the page you have requested
>>     http://www.ieee802.org/16/private/drafts/netman/80216g-06_002.pdf
>> does not exist on this site."
>>
>> Its title is "Management Plane Procedures and Services".  Is it this 
>> document that describes what GPCS should look like?
>>
>> Alex
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Dec 2006 14:06:12 +0100

> That's my suggestion...:-)

Makes sense to me.  Could we add GPCS term to the list as well?  As 
being developped by 802.16g?  It's mentioned in the other threads here.

If(!) we have common understanding of that complete list of 802.16 
Convergence Sublayers, then I think it makes sense to tackle separate 
documents, or separate sections of documents or of existing documents, 
of "IPv6 over x-CS" for each x.  Probably the "IPv6 over IPv4CS" would 
be empty.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 06 Dec 2006 07:13:24 -0600

Daniel,

> think it is a critical aspect from the 16ng perspective

Well.... I think it is best to use common terms otherwise there will be
issues when we discuss the document or have someone from IEEE review the
document. But it may be okay if you specified the terms used in IEEE 802.16
and how they are refered to in the IETF doc in the terminology section.

> It is modified terms from the 802.16 Std too. Isn't it ?

No. The above is straight from the 802.16 spec.

> my thought

> o IPv4CS: It means IPv4 specific part of the Packet CS

There is no IPv4 specific part of the packet CS. There is only the IP
specific part of the packet CS which deals with IPv4 and IPv6.

-Raj