Subject: [16NG] Re: 16NG Digest, Vol 5, Issue 13

From: "김상언" <[email-masked]>
Date: Tue, 17 Apr 2007 17:24:01 +0900

2007/4/17, [email-masked] <[email-masked]>:
>
> Send 16NG mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www1.ietf.org/mailman/listinfo/16ng
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of 16NG digest..."
>
>
> Today's Topics:
>
>   1. ??: [16NG] What is your opinions regarding to IEEE802.16?
>      (John.zhao)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 17 Apr 2007 10:31:36 +0800
> From: "John.zhao" <[email-masked]>
> Subject: ??: [16NG] What is your opinions regarding to IEEE802.16?
> To: '???' <[email-masked]>,      'qinxia' <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked],
>        [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
> Hi folks
>
>
>
>       See comments inline.
>
>
>
>       Best Rgds,
>
> Thanks,
>
>
>
> John.zhao
>
>
>
> > -----Original Message-----
> > From: ??? [mailto:[email-masked]]
> > Sent: Monday, April 16, 2007 10:07 AM
> > To: [email-masked]; [email-masked];
> > [email-masked]
> > Cc: [email-masked]
> > Subject: [16NG] What is your opinions regarding to IEEE802.16 ?
> >
> > Dear Authors of the RFC 4840,
> >
> > IEEE 802.16 specifies several convergence sublayer (CS)
> > including ATM, IPv4 packet, IPv6 packet, IPv4 over EThernet,
> > IPv6 over Ethernet, IPv4 over VLAN, IPv6 over VLAN and more.
> > Also, it should be used management plane to identify CS
> > because 802.16 MAC frame does not have a CS identification field.
> >
>
> [zhao] I think IEEE802.16 is ready to provide only one kind of CS
> simultaneously to one MN.

In the view of implementation, we can understand either IPv4 or IPv6 as well
as both IPv4 and IPv6 based on IEEE802.16-2004 REG-REQ/RSP message which can
refer to section 11.7.4 on page pp668.
If we used both IPv4 and IPv6 at the REG-REQ/RSP message, BS should resolve
the packet type.

> Whereas, IP family uses its header to identify for the upper
> > layer service.
> > For example, Ethernet type at the Ethernet header is used
> > 0X0800 and 0X86DD for IPv4, IPv6 respectively.
> > The protocol field at the IP header uses for identification
> > of the upper layer protocol, in reference at
> > http://www.iana.org/assignments/protocol-numbers
> >
> > If the IEEE802.16 systems are implemented for IPv4 packet
> > only. It doesn't matter.
> > When we try to dual stack, both native IPv4 over IEEE802.16
> > and native IPv6 IEEE802.16, it is more difficult than
> > Ethernet based IP due to absence of CS type at the 16 MAC header.
> >
> ==> why does MAC header need to identify the CS type of frame?
> Even though CS type is indicated on the very  MAC header, the frame is
> still needed
> to be classified with classifier due to QoS support.
> The inner information such as IP 5 turple is still needed sometimes.
>
>
>
> According to the section 3.1 of RFC4840, it is recommended that
> "Link-layer protocols should enable network packets (IPv4, IPv6, ARP, etc.)
> to be demultiplexed in the link layer"
>
>
>
> [zhao] The IEEE802.16 provide the Classifier mechanism to do the
> distinguishment.

RFC4840 rescommends as following in section 3.2 and 3.3
"Upper-layer-specific classification schemes should be avoided." and
"Link-layer classification schemes should not rely on the contents of
higher-layer headers." respectively.
Also, your comments are inappropriate for section 3.1.

> Even if connection identifier (CID) field of 16 header can be
> > used between base station and subscriber station, multiple CS
> > should be processed at the BS.
> > Also, prefix model IP family over IEEE802.16 such as shared
> > prefix and per-MS prefix impacts on network architecture and
> > implementation.
> >
>
> > Which is preferred prefix model?
> > Are you agree to require dual stack over IEEE 802.16 system
> > (may be stupid question, but is is possible IPv6 over IPv4
> > tunnel for IPv6 packet delivery) ?
> > What is your preferred CS ? and Why?
> >
>
> [zhao]Do you plan to provide the IPv4 and IPv6 support simultaneously.

Yes, We are seriously considering technical issues to support IPv4 and IPv6
simultaneously.

Before we mention about how to do this, I think it is the best to clarify
> why we need to do this.
>
>
> > thanks
>
>
> End of 16NG Digest, Vol 5, Issue 13
> ***********************************
>
> ------------------------------------------------
> Sang-Eon Kim
> Senior Researcher
> Infra. Lab., KT
> 139-791, Woomyeon-dong, Seocho-gu, Seoul, Korea
>
> Voice: +82-2-526-6117
> Mobile: +82-10-3073-4084
> E-mail: [email-masked]
> ------------------------------------------------
_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: qinxia <[email-masked]>
Date: Tue, 17 Apr 2007 17:43:27 +0800

> Sent: Tuesday, April 17, 2007 4:24 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [16NG] Re: 16NG Digest, Vol 5, Issue 13
> 
> 
> 
> 	Subject: ??: [16NG] What is your opinions regarding to 
> IEEE802.16 ?
> 	> From: ??? [mailto:[email-masked] ]
> 	[zhao] I think IEEE802.16 is ready to provide only one 
> kind of CS simultaneously to one MN.
> 
>  
> In the view of implementation, we can understand either IPv4 
> or IPv6 as well as both IPv4 and IPv6 based on 
> IEEE802.16-2004 REG-REQ/RSP message which can refer to 
> section 11.7.4 on page pp668. 
> If we used both IPv4 and IPv6 at the REG-REQ/RSP message, BS 
> should resolve the packet type. 
> 
> 
> 	Even though CS type is indicated on the very  MAC 
> header, the frame is still needed
> 	According to the section 3.1 of RFC4840, it is 
> recommended that "Link-layer protocols should enable network 
> packets (IPv4, IPv6, ARP, etc.) to be demultiplexed in the link layer"
> 	
> 	
> 	
> 	[zhao] The IEEE802.16 provide the Classifier mechanism 
> to do the distinguishment.
> 
>  
> "Upper-layer-specific classification schemes should be 
> avoided." and "Link-layer classification schemes should not 
> rely on the contents of higher-layer headers." respectively. 
[qx] yes, I agree that "Upper-layer-specific classification schemes should be
avoided."  in case of transport over link layer.  Moreover, if we mean to meet
requirement from QOS or charging by means of classification.   Classification is not
ever a bad boy. 

> Yes, We are seriously considering technical issues to support 
> IPv4 and IPv6 simultaneously.

[qx] to be frank, I am confused on this argument, do you mean, address dual stack
communication problems within MAC layer?

> 
> 
> 	Before we mention about how to do this, I think it is 
> the best to clarify why we need to do this.
> 	
> 	
> 	> thanks
> 	
>

---

From: "John.zhao" <[email-masked]>
Date: Wed, 18 Apr 2007 14:25:58 +0800

Hi,folks
     See my comments.
	For read convenience, I keep the discussion only as following and
remove the long header from many previous email.

	Best Rgds,
Thanks,
> should resolve the packet type. 
[zhao]As we have discussed many times before in this work group. Even you
want to utilize some bit to indicate the IPv4 or IPv6. The 'IP version'
field isn't a good choice. Because IEEE only assign them to indicate the IP
version used on second management connection. But others is available,
maybe. To this point, I think if we come back to discuss about the
implementation, then everything is possible, right?
> Also, your comments are inappropriate for section 3.1.
[qx] yes, I agree that "Upper-layer-specific classification schemes should
be
avoided."  in case of transport over link layer.  Moreover, if we mean to
meet
requirement from QOS or charging by means of classification.
Classification is not
ever a bad boy. 

> IPv4 and IPv6 simultaneously.

[qx] to be frank, I am confused on this argument, do you mean, address dual
stack
communication problems within MAC layer?