Subject: RE: [Monami6] New draft submitted: draft-park-mis-00.txt

From: "Chulhyun Park" <[email-masked]>
Date: Wed, 21 Jun 2006 17:53:11 +0900

Hi Michael,

Here is the description about options, from 4.2 in RFC 2460 : 

4.2  Options

   Two of the currently-defined extension headers -- the Hop-by-Hop
   Options header and the Destination Options header -- carry a variable
   number of type-length-value (TLV) encoded "options", of the following
   format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |  Option Type  |  Opt Data Len |  Option Data
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

      Option Type          8-bit identifier of the type of option.

      Opt Data Len         8-bit unsigned integer.  Length of the Option
                           Data field of this option, in octets.

So the option data length should be the length of 'option data', not full option length, and in the traffic control option, the option data length is 1+2=3 (1 for service type field, and 2 for preference value field)

I think I should modify 'option length field' in Fig.3 into 'option data length'.
Will it be OK?

Regards,
Park.

Chulhyun Park, MS student
Multimedia and mobile communications Lab. 
Seoul University

[email-masked]
________________________________________
From: Michael Ye [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 5:42 PM
To: 'Chulhyun Park'; [email-masked]
Subject: RE: [Monami6] New draft submitted: draft-park-mis-00.txt

Hi Park,
    I think the figure 3 is not right.
    If the lenth is 3, 5 octets should be reserved,I think.

BR,
Michael

________________________________________
From: Chulhyun Park [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 4:16 PM
To: [email-masked]; [email-masked]
Subject: RE: [Monami6] New draft submitted: draft-park-mis-00.txt

I made a mistake in Fig.3 of my draft : The option type field should be 8 bits long.
Anyway, I cannot understand what you meant exactly. Can you give me more detailed question?

Chulhyun Park, MS student
Multimedia and mobile communications Lab. 
Seoul University

[email-masked]
________________________________________
From: Michael Ye [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 4:05 PM
To: 'Chulhyun Park'; [email-masked]
Subject: RE: [Monami6] New draft submitted: draft-park-mis-00.txt

Hi Park,
    Traffic control option is option of the Hop-by-Hop Options Header.
In section 4.3 of  RFC2460,
 
Options              Variable-length field, of length such that the
                        complete Hop-by-Hop Options header is an integer
                        multiple of 8 octets long.  Contains one or more
                        TLV-encoded options, as described in section
                        4.2.
BR,
Michael

________________________________________
From: Chulhyun Park [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 1:34 PM
To: [email-masked]
Cc: 'Michael Ye'
Subject: RE: [Monami6] New draft submitted: draft-park-mis-00.txt
Hi Michael, thanks for your comment.

I’m afraid that somewhat you confused.
The option type field and the option length field are parts of “option”, which will be carried in an IPv6 hop-by-hop options header or an IPv6 destination options header. The option type field in an option is used to distinguish options from each other, so we cannot use the field for other purpose. 

And we specified that the service type value from 0 to 3 matches each of 4 traffic classes. 
If any additional service type needed, you can use a reserved value.

Regards, 
Park.

Chulhyun Park, MS student
Multimedia and mobile communications Lab. 
Seoul University

[email-masked]
________________________________________
From: Michael Ye [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 11:38 AM
To: 'Monami6 WG'
Cc: 'Chulhyun Park'
Subject: RE: [Monami6] New draft submitted: draft-park-mis-00.txt

Hi Park,
    
In secton 4.2 of this draft,Option length is three.I don't know if it is appropriate.
 
    Sevice type hint four packets,just in section 4.2.1.
        But if there is a new type packet, you will have to change the Sevice type or add one value to the Sevice type。
    So I suggest that you use a abstract model value for sevice type instead of actual type. 
 
BR,
Michael

________________________________________
From: ??? [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 9:58 AM
To: [email-masked]
Subject: [Monami6] New draft submitted: draft-park-mis-00.txt
Dear all,

We submitted a new draft about interface selection framework in a multihomed mobile router. 
A URL for the internet draft is http://www.ietf.org/internet-drafts/draft-park-mis-00.txt
Here is the abstract:

“In this draft, we discuss how to make use of multiple interfaces in a
single mobile router.  We will focus on the scenario in which each
interface is attached to different access network.  Especially, we
propose how a mobile router selects proper interfaces to provide
services to different traffic flows.  We suggest two methods to do
that.  First we suggest a new option carried in IPv6 hop-by-hop
options header, and we will use the flow label field in the IPv6 main
header.  The flow label field is used to distinguish different
packets belonging to different traffic flows.  New option contains a
service type value and a preference value.  A servie type value is
used for traffic classification, and a preference value enables
mobile router to control the traffic in detail.  The propsed multiple
interface selection mechanism in a multihomed mobile router (MMR)
chooses an appropriate interface for each flow, depending on traffic
requirements and access network characteristics.”

Any feedback is welcome, of course.

Regards,
Park.

Chulhyun Park, MS student
Multimedia and mobile communications Lab. 
Seoul University

[email-masked]

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Michael Ye <[email-masked]>
Date: Wed, 21 Jun 2006 17:10:07 +0800

Hi Park,

	Yes

BR
Michael
 
-----Original Message-----
From: Chulhyun Park [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 4:53 PM
To: 'Michael Ye'; [email-masked]
Subject: RE: [Monami6] New draft submitted: draft-park-mis-00.txt

Hi Michael,

4.2  Options

So the option data length should be the length of 'option data', not full
option length, and in the traffic control option, the option data length is
1+2=3 (1 for service type field, and 2 for preference value field)

I think I should modify 'option length field' in Fig.3 into 'option data
length'.
Will it be OK?

Regards,
Park.

[email-masked]

Hi Park,

BR,
Michael

I made a mistake in Fig.3 of my draft : The option type field should be 8
bits long.
Anyway, I cannot understand what you meant exactly. Can you give me more
detailed question?

[email-masked]

Hi Park,

________________________________________
From: Chulhyun Park [mailto:[email-masked]]
Sent: Wednesday, June 21, 2006 1:34 PM
To: [email-masked]
Cc: 'Michael Ye'
Subject: RE: [Monami6] New draft submitted: draft-park-mis-00.txt Hi
Michael, thanks for your comment.

I’m afraid that somewhat you confused.
The option type field and the option length field are parts of “option”,
which will be carried in an IPv6 hop-by-hop options header or an IPv6
destination options header. The option type field in an option is used to
distinguish options from each other, so we cannot use the field for other
purpose. 

And we specified that the service type value from 0 to 3 matches each of 4
traffic classes. 
If any additional service type needed, you can use a reserved value.

Regards,
Park.

[email-masked]

Hi Park,
    
In secton 4.2 of this draft,Option length is three.I don't know if it is
appropriate.
 
    Sevice type hint four packets,just in section 4.2.1.
        But if there is a new type packet, you will have to change the
Sevice type or add one value to the Sevice type。
    So I suggest that you use a abstract model value for sevice type instead
of actual type. 
 
BR,
Michael

________________________________________
From: ??? [mailto:[email-masked]]
Sent: Wednesday, June 21, 2006 9:58 AM
To: [email-masked]
Subject: [Monami6] New draft submitted: draft-park-mis-00.txt Dear all,

We submitted a new draft about interface selection framework in a multihomed
mobile router. 
A URL for the internet draft is
http://www.ietf.org/internet-drafts/draft-park-mis-00.txt
Here is the abstract:

“In this draft, we discuss how to make use of multiple interfaces in a
single mobile router.  We will focus on the scenario in which each interface
is attached to different access network.  Especially, we propose how a
mobile router selects proper interfaces to provide services to different
traffic flows.  We suggest two methods to do that.  First we suggest a new
option carried in IPv6 hop-by-hop options header, and we will use the flow
label field in the IPv6 main header.  The flow label field is used to
distinguish different packets belonging to different traffic flows.  New
option contains a service type value and a preference value.  A servie type
value is used for traffic classification, and a preference value enables
mobile router to control the traffic in detail.  The propsed multiple
interface selection mechanism in a multihomed mobile router (MMR) chooses an
appropriate interface for each flow, depending on traffic requirements and
access network characteristics.”

Regards,
Park.

[email-masked]