Subject: [MIPSHOP-MIH-DT] Short notes

From: Telemaco Melia <[email-masked]>
Date: Wed, 05 Sep 2007 16:23:51 +0200

Attendees: Gabor, Juan Carlos, Telemaco, Nada, Richard, Juan Carlos, (Subir joined later)

Notes:

-- Regarding Sam’s 2.3
Gabor: When discovery happens, the MN decides where it wants to perform the discovery of mobility services. 
At that point, only the suggested option will be used

-- Section 4.1
It could require some IP level description in case that later on we decide to rely on some extra features, 
such as IPSec or IP Fragmentation

-- Add a 4.3 section describing the collocation of services beyond what Gabor mentioned in his document (JCZ)

-- Nada: Update about Transport
Some results are available. No surprising results.
Should discussion and comparison between UDP/TCP be added in the text?

-- Nada: Middlebox traversal should be made a subsection

-- Gabor: Include data about message sizes and parameters that lead to recommending UDP and TCP the way we do

-- Gabor: DNSSEC is not widely used and the benefit is not clear. It’s use is questionable.

Action points:

+ ALL -- input to be provided by Thursday evening, first integrated version by Friday, target submission next Monday
+ Tele-- revise introduction and terminology section.
+ JCZ -- add a paragraph in section 3 about co-location of the mobility services
+ Tele-- add in Section 4 drawings about scenario 3 and scenario 4
+ Subir-- to revise 4.1 according to the comment above
+ Nada -- provide text for section 6
+ Tele/JCZ -- provide flows for section 7
+ Gabor -- revise section 8

Thanks JCZ for the input.

tele

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: <[email-masked]>
Date: Wed, 5 Sep 2007 10:03:38 -0500

Folks,

I am still thinking about this transport selection. What was the
argument for preferring UDP instead of TCP for ES/CS? I know about tcp
connection setup time, but that happens only once at the beginning, and
does not affect the delay afterwards. 

Some folks asked me if we did consider SCTP. The availability of SCTP in
the terminals might be a problem, but I was told that might fit best to
those ES/CS services.

Any comments?

Nada, is there an SCTP module in ns you could use to run some
simulations with sctp too?

Thanks,
- gabor 

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 7:24 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] Short notes

Attendees: Gabor, Juan Carlos, Telemaco, Nada, Richard, Juan Carlos,
(Subir joined later)

Notes:

-- Regarding Sam's 2.3
Gabor: When discovery happens, the MN decides where it wants to perform
the discovery of mobility services. 
At that point, only the suggested option will be used

-- Section 4.1
It could require some IP level description in case that later on we
decide to rely on some extra features, such as IPSec or IP Fragmentation

-- Add a 4.3 section describing the collocation of services beyond what
Gabor mentioned in his document (JCZ)

-- Gabor: Include data about message sizes and parameters that lead to
recommending UDP and TCP the way we do

-- Gabor: DNSSEC is not widely used and the benefit is not clear. It's
use is questionable.

Action points:

+ ALL -- input to be provided by Thursday evening, first integrated 
+ version by Friday, target submission next Monday
+ Tele-- revise introduction and terminology section.
+ JCZ -- add a paragraph in section 3 about co-location of the mobility 
+ services
+ Tele-- add in Section 4 drawings about scenario 3 and scenario 4
+ Subir-- to revise 4.1 according to the comment above Nada -- provide 
+ text for section 6 Tele/JCZ -- provide flows for section 7 Gabor -- 
+ revise section 8

tele

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 05 Sep 2007 17:25:06 +0200

If we recommend TCP are we assuming a mobility protocol to be present in 
the MN?

tele

-- 
Dr. Telemaco Melia			[email-masked]
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.
NEC Laboratories Europe
Network Division			
Kurfürsten-Anlage 36		
69115 Heidelberg
GERMANY	  

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: <[email-masked]>
Date: Wed, 5 Sep 2007 10:39:54 -0500

Do we need to? 

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 8:25 AM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Short notes

If we recommend TCP are we assuming a mobility protocol to be present in the MN?

tele

[email-masked] wrote:
> connection setup time, but that happens only once at the beginning, 
> and does not affect the delay afterwards.
>
> Some folks asked me if we did consider SCTP. The availability of SCTP 
> in the terminals might be a problem, but I was told that might fit 
> best to those ES/CS services.
>
> Any comments?
>
> Gabor: When discovery happens, the MN decides where it wants to 
> perform the discovery of mobility services.
> -- Add a 4.3 section describing the collocation of services beyond 
> what Gabor mentioned in his document (JCZ)
>
> + JCZ -- add a paragraph in section 3 about co-location of the 
> + mobility services

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 05 Sep 2007 18:26:29 +0200

Ok the more general question is: what do we do when we have an active 
session with the PoS and we perform HO?
If we want to keep reachability (e.g. the MoS can always send packets to 
the MN) we need Mobile IP or the like...we should probably introduce 
text about this in the draft.
what do you think?

tele

---

From: Subir Das <[email-masked]>
Date: Wed, 05 Sep 2007 12:33:55 -0400

Since I missed the discussion part,  I need some clarifications on security.
I know DNSSEC is not widely deployed but that's the only IETF recommended
security framework available. DHCP authentication is also not widely 
deployed
Security feature is optional to me. So it should be fine, IMO. Did we 
decide
anything?

Btw, I will reflect the comment regarding 4.1. There is a comment in the 
document
regarding  DHCP/AAA picture. What was the conclusion?

-Subir

Telemaco Melia wrote:
> perform the discovery of mobility services. At that point, only the 
> suggested option will be used
>
> -- Section 4.1
> version by Friday, target submission next Monday
> mobility services

---

From: <[email-masked]>
Date: Wed, 5 Sep 2007 11:40:37 -0500

Question is, what is the threat if DNSSEC is not used? You contact a
fake MoS which you can not authenticate with. So? There is some
potential for DoS, which DNSSEC can avoid. We can mention this in the
security section, but I am reluctant saying that DNSSEC MUST be used for
MoS discovery.

- gabor 

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 9:34 AM
To: Telemaco Melia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Short notes

Since I missed the discussion part,  I need some clarifications on
security.
I know DNSSEC is not widely deployed but that's the only IETF
recommended security framework available. DHCP authentication is also
not widely deployed Security feature is optional to me. So it should be
fine, IMO. Did we decide anything?

Btw, I will reflect the comment regarding 4.1. There is a comment in the
document regarding  DHCP/AAA picture. What was the conclusion?

-Subir

---

From: <[email-masked]>
Date: Wed, 5 Sep 2007 11:42:50 -0500

this seems to be a generic HO problem, isn't it? we could have some text about this.
my original question was about the transport, eg using tcp or sctp instead of udp. 
 
- gabor

________________________________

Sent: Wednesday, September 05, 2007 9:26 AM

Ok the more general question is: what do we do when we have an active session with the PoS and we perform HO?
If we want to keep reachability (e.g. the MoS can always send packets to the MN) we need Mobile IP or the like...we should probably introduce text about this in the draft.
what do you think?

tele

	Do we need to? 
	
	-----Original Message-----
	From: ext Telemaco Melia [mailto:[email-masked]] 
	Sent: Wednesday, September 05, 2007 8:25 AM
	To: Bajko Gabor (Nokia-SIR/MtView)
	Cc: [email-masked]
	Subject: Re: [MIPSHOP-MIH-DT] Short notes

	tele

		Folks,

		
		Any comments?

		Thanks,
		- gabor
		
		-----Original Message-----
		From: ext Telemaco Melia [mailto:[email-masked]]
		Sent: Wednesday, September 05, 2007 7:24 AM
		To: [email-masked]
		Subject: [MIPSHOP-MIH-DT] Short notes

		Notes:
		
		-- Regarding Sam's 2.3
		
		-- Section 4.1
		It could require some IP level description in case that later on we 
		decide to rely on some extra features, such as IPSec or IP 
		Fragmentation

		

		Action points:

		
		tele

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 05 Sep 2007 18:53:58 +0200

I will propose a picture for this.... including DNS. We can then discuss 
if we like it or not...

tele

Subir Das wrote:
> Btw, I will reflect the comment regarding 4.1. There is a comment in 
> the document
>> -- Gabor: Include data about message sizes and parameters that lead 
>> to recommending UDP and TCP the way we do
>>

---

From: Subir Das <[email-masked]>
Date: Wed, 05 Sep 2007 12:55:14 -0400

There are two issues: one is DoS as you have described and another is 
providing false information.
Currently we do not mention that DNSEC MUST be used. It is SHOULD and 
also a recommendation.
My understanding is security for both DHCP and DNS are "SHOULD" not "MUST".

---

From: Subir Das <[email-masked]>
Date: Wed, 05 Sep 2007 13:06:24 -0400

Ok, I will insert it then..

Telemaco Melia wrote:
> I will propose a picture for this.... including DNS. We can then 
> discuss if we like it or not...
>
> tele
>
> Subir Das wrote:
>> recommended

---

From: Subir Das <[email-masked]>
Date: Wed, 05 Sep 2007 16:29:50 -0400

While adding the AAA/DHCP figure, I found some structural 
inconsistencies in the document.
I think we should add all the flows in Section 5 where MoS discovery has 
been described.
Otherwise, it is just hanging in Section 4 after the paragraph where we 
say that "The dynamic
assignment methods are described in Section 5." If you agree, I can try 
to put them in appropriate
subsections. I also agree that we need to add high level flows for DNS 
discovery.

---

From: golmie <[email-masked]>
Date: Wed, 05 Sep 2007 16:36:54 -0400

Gabor,

>does not affect the delay afterwards. 
Delays w/ TCP are mainly due to retransmissions in the case of network 
loss and congestion conditions.
Although reliable, TCP may not be able to meet the stringent delay 
requirements for ES/CS.

>simulations with sctp too?
We could certainly do that. However, we would need few more weeks to 
obtain and analyze the results since we're not familar with the module.

-Nada

---

From: Sam Xia <[email-masked]>
Date: Thu, 06 Sep 2007 09:43:03 +0800

> 
> Question is, what is the threat if DNSSEC is not used? You 
> contact a fake MoS which you can not authenticate with. So? 
> There is some potential for DoS, which DNSSEC can avoid. We 
> can mention this in the security section, but I am reluctant 
> saying that DNSSEC MUST be used for MoS discovery.

SAM> DNSSec and authenticating option for DHCP can only protect the messages
themself from/to DNS server and DHCP Server.  The two method can help
improve security performance to some degree. But my concern is how to deal
with the security issues between MN and MIH provider. These are differenct
things. I don't object whether to use DNSSec or DHCP authentication
option(in fact, i don't care because the two methods can not deal with the
security issues described in .21 draft). 

views?

> recommended security framework available. DHCP authentication 
> is also not widely deployed Security feature is optional to 
> me. So it should be fine, IMO. Did we decide anything?
> 
> Btw, I will reflect the comment regarding 4.1. There is a 
> comment in the document regarding  DHCP/AAA picture. What was 
> the conclusion?
> 
> -Subir
> 
> Telemaco Melia wrote:

---

From: Sam Xia <[email-masked]>
Date: Thu, 06 Sep 2007 09:47:50 +0800

> 
> There are two issues: one is DoS as you have described and 
> another is providing false information.
> Currently we do not mention that DNSEC MUST be used. It is 
> SHOULD and also a recommendation.

I am surprised at why we should pay too much attention to issues not
introduced by MIH transport protocol.  These security issues are general for
DNS and DHCP.

> contact a 
> > security section, but I am reluctant saying that DNSSEC 
> MUST be used 
> > for MoS discovery.
> >
> > - gabor
> >
> > not widely deployed Security feature is optional to me. So 
> it should 
> > be fine, IMO. Did we decide anything?
> >
> comment in 
> > the document regarding  DHCP/AAA picture. What was the conclusion?
> >
> > -Subir
> >
> > Telemaco Melia wrote:
> >   
> >> to
> >> + Subir-- to revise 4.1 according to the comment above Nada -- 
> >> + provide
> >>     
> >
> >

---

From: Sam Xia <[email-masked]>
Date: Thu, 06 Sep 2007 09:58:00 +0800

Ok the more general question is: what do we do when we have an active
session with the PoS and we perform HO?
If we want to keep reachability (e.g. the MoS can always send packets to the
MN) we need Mobile IP or the like...we should probably introduce text about
this in the draft.
what do you think?

SAM>  AFAIK, Mobile IP is not deployed widely. Why should we make this
assumtion?  And maybe Mobile IP is the user of MIH Function; and on the
other hand, if MIH Funtion was user of mobile ip, a deadlock would be
expected?
_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Sam Xia <[email-masked]>
Date: Thu, 06 Sep 2007 14:32:35 +0800

> Delays w/ TCP are mainly due to retransmissions in the case 
> of network loss and congestion conditions.
> Although reliable, TCP may not be able to meet the stringent 
> delay requirements for ES/CS.

Sam>
If no congestion, TCP works just as UDP for ES, CS. Right?
When congestion happens, UDP does't work. Right?

> >in the terminals might be a problem, but I was told that 
> might fit best 
> >to those ES/CS services.
> >
> >Any comments?
> >
> We could certainly do that. However, we would need few more 
> weeks to obtain and analyze the results since we're not 
> familar with the module.
> 
> -Nada
> 
> >Thanks,
> >- gabor
> >

---

From: Telemaco Melia <[email-masked]>
Date: Thu, 06 Sep 2007 12:25:47 +0200

Subir, all,

One note on the DHCP/AAA interaction.

Draft draft-ietf-mip6-bootstrapping-integrated-05 discusses and solves a similar issue.
Please refer to figure 1.
Additionally I would like to point out the following text:
" The mobile node sends a DHCPv6 Information Request message [RFC3315] to the
All_DHCP_Relay_Agents_and_Servers multicast address. In this message the mobile node (DHCP
client) SHALL include the Option Code for Home Network Identifier Option [HIOPT] in the
OPTION_ORO, Home Network Identifier Option with id-type set to 0. The mobile node SHALL also include the
OPTION_CLIENTID to identify itself to the DHCP server."

By including this option into the information request the MN is able to perform selection for the allocation of the HA,
either in visited or in home.

The bottom line is: do we want to support a similar functionality?

tele

Subir Das wrote:
> I think we should add all the flows in Section 5 where MoS discovery 
> has been described.
> Otherwise, it is just hanging in Section 4 after the paragraph where 
> we say that "The dynamic
> assignment methods are described in Section 5." If you agree, I can 
> try to put them in appropriate
>>> Security feature is optional to me. So it should be fine, IMO. Did 
>>> we decide
>>> anything?
>>>

---

From: <[email-masked]>
Date: Thu, 6 Sep 2007 07:20:00 -0500

Hi Nada,

<gabor> ok, I see. I think this should be pointed out in the draft. We
also have to make sure that the MIH level ACK we use with UDP acts
'faster' than tcp in case of loss. In case of congestion, I guess it
doesn't make a difference.

<gabor> this would be a great addition to the story

Thanks!
- gabor

-Nada

---

From: Telemaco Melia <[email-masked]>
Date: Thu, 06 Sep 2007 14:48:50 +0200

Just to follow up:

                      Visited               |   Home
                                            |
                                            |
                        +-------+           |        +-------+
                        |       |           |        |       |
                        |AAAV   |-----------|--------|AAAH   |
                        |       |           |        |       |
                        |       |           |        |       |
                        +-------+           |        +-------+
                            |               |
                            |               |
                            |               |
                            |               |
                            |               |       +--------+
                            |               |       |        |
                            |               |       |  MoSh  |
                        +-----+    +------+ |       +--------+
            +----+      |     |    |DHCP  | |
            | MN |------| NAS/|----|Server| |
            +----+      |Relay|    |      | |
                        +-----+    +------+ |
                                            |
                                            |
                                            |
                                            |
                                            |
                                            |

Comments?

tele

Telemaco Melia wrote:
>> subsections. I also agree that we need to add high level flows for 
>> DNS discovery.
>>
>>
>> Telemaco Melia wrote:
>>>> security framework available. DHCP authentication is also not 
>>>> widely deployed
>>>> Btw, I will reflect the comment regarding 4.1. There is a comment 
>>>> in the document
>>>>> perform the discovery of mobility services. At that point, only 
>>>>> the suggested option will be used
>>>>>
>>>>> -- Section 4.1
>>>>> It could require some IP level description in case that later on 
>>>>> we decide to rely on some extra features, such as IPSec or IP 
>>>>> Fragmentation
>>>>>
>>>>> -- Gabor: Include data about message sizes and parameters that 
>>>>> lead to recommending UDP and TCP the way we do
>>>>>
>>>>> + ALL -- input to be provided by Thursday evening, first 
>>>>> integrated version by Friday, target submission next Monday
> ------------------------------------------------------------------------
>

---

From: Subir Das <[email-masked]>
Date: Thu, 06 Sep 2007 09:57:43 -0400

Tele,
I need to refresh my memory regarding this draft. Before I do that, let 
me clarify few things
with you.

-- DHCPv6 messages exchange are happening  before access authentication 
or after authentication success..

-- I assume we want to allow similar things for DHCPv4 case as well.

-- Are we defining MOS identifier option with id-type = 0?

-Subir

---

From: Subir Das <[email-masked]>
Date: Thu, 06 Sep 2007 10:00:09 -0400

Yes, this is good and I was thinking along the same line in the call 
flow. But do we
plan to include the architecture as well?

Telemaco Melia wrote:
>>>>>> -- Add a 4.3 section describing the collocation of services 
>>>>>> beyond what Gabor mentioned in his document (JCZ)
>>>>>>

---

From: Subir Das <[email-masked]>
Date: Thu, 06 Sep 2007 10:10:04 -0400

The security between MN and MIH  can be handled  once .21 provides a
framework or some guidelines/features on MIH level security. This is
currently a discussion item of the new Study Group.

Sam Xia wrote:
>>> Attendees: Gabor, Juan Carlos, Telemaco, Nada, Richard, 
>>>       
>> Juan Carlos, 
>>     
>>> (Subir joined later)
>>>
>>> Notes:
>>>
>>> -- Regarding Sam's 2.3
>>> Should discussion and comparison between UDP/TCP be added 
>>>       
>> in the text?
>>     
>>> -- Gabor: Include data about message sizes and parameters 
>>>       
>> that lead to
>>
>>     
>>> -- Gabor: DNSSEC is not widely used and the benefit is not 
>>>       
>> clear. It's
>>
>>     
>>> use is questionable.
>>>
>>>
>>> Action points:
>>>
>>> + Subir-- to revise 4.1 according to the comment above Nada 
>>>       
>> -- provide
>>
>>     
>>> + text for section 6 Tele/JCZ -- provide flows for section 
>>>       
>> 7 Gabor -- 
>>     
>>> + revise section 8
>>>
>>>

---

From: Subir Das <[email-masked]>
Date: Thu, 06 Sep 2007 10:11:35 -0400

Remember we are addressing two issues: Discovery and Transport. These
security issues are related to discovery not for transport.

Sam Xia wrote:
>>> potential for DoS, which DNSSEC can avoid. We can mention 
>>>       
>> this in the 
>>     
>>> recommended security framework available. DHCP 
>>>       
>> authentication is also 
>>     
>>>> perform the discovery of mobility services. At that point, 
>>>>         
>> only the 
>>     
>>>> It could require some IP level description in case that 
>>>>         
>> later on we 
>>     
>> that lead

---

From: <[email-masked]>
Date: Thu, 6 Sep 2007 10:27:36 -0500

Nada,

I just got word that SCTP uses the same retransmission timeout (200ms)
as TCP. So probably running the simulations with SCTP would give exactly
the same result as running it with TCP.

- gabor

-----Original Message-----
From: ext [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 5:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

Hi Nada,

Thanks!
- gabor

-Nada

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 6 Sep 2007 11:40:23 -0400

One more point about using UDP with MIH level ACK as compared to TCP
besides the faster retransmissions is that the MIH controls better these
retransmissions, so in case of events such as measurements, the MIH
could decide whether to retransmit the same old information or it could
now transmit an updated one (if available).

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: September 6, 2007 2:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

Hi Nada,

Thanks!
- gabor

-Nada

---

From: <[email-masked]>
Date: Thu, 6 Sep 2007 12:43:11 -0500

I am not sure how MIH could control the retransmissions better than tcp
though. ES/CS datagrams are usually one message, so there is no time to
measure and adjust the rtt. You need to make a rough estimate without
knowing the network conditions. You could say that the retransmission
timeout for MIH must be less than 200ms, and assume you are better off
than with using tcp. In reality that is not true, as tcp does have the
fast retransmit algorithm ... (but that can be applied only if the MIH
datagram would consist of at least 3 tcp segments)

- gabor

-----Original Message-----
From: ext Zuniga, Juan Carlos
[mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 8:40 AM
To: Bajko Gabor (Nokia-SIR/MtView); [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: September 6, 2007 2:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

Hi Nada,

Thanks!
- gabor

-Nada

---

From: Nada Golmie <[email-masked]>
Date: Thu, 06 Sep 2007 13:43:36 -0400

Hello All,

Please find in the attachment text for section 6. I've tried as much as 
possible to capture our comments on the transport selection issue. Feel 
free to modify as you see fit.

I have also included a set of slides with our preliminary simulation 
results to date - simulations are still running for multiple seeds but 
the gist of it is there.

Going forward we had identified the following additional items for us to 
study:
(1) queuing priority - which involves coming up with a scheme at the MIH 
layer to address transmission priorities
(2) fragmentation - without coming up with a scheme at the MIH layer, 
where we would be comparing TCP to IP fragmentation.
(3) SCTP - I agree with Gabor, for our purposes, the results would look 
like TCP given the same retransmission timeout.  Unless we would use 
more complex scenarios including for example with multiple interfaces, 
multiple routes in order to take advantage of SCTP's multi-homing features.

Anything else I missed?  or thoughts about additional issues that people 
would like to address? Let me know.

I have a slight preference to tackle item (3) first, unless I hear 
otherwise.

Logistically, I will be on vacation starting tomorrow and will have no 
or limited email connectivity until September 18th. Therefore, I will 
miss the telecon next week.

Best wishes,

-Nada

-- 
Nada Golmie, Ph.D. 
Manager, High Speed Network Technologies Group
National Institute of Standards and Technology
100 Bureau Dr. Stop 8920
Gaithersburg, MD 20899
Email: [email-masked]
Phone: (301) 975-4190
Fax:   (301) 590-0932
Web: http://w3.antd.nist.gov

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 6 Sep 2007 13:50:50 -0400

I meant ES measurements inside the payload of the MIH message, not
measuring the network conditions or rtt.

As for retransmission timeout, I think that it wouldn't hurt if we
provided some guidelines.

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: September 6, 2007 1:43 PM
To: Zuniga, Juan Carlos; [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

- gabor

-----Original Message-----

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: September 6, 2007 2:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

Hi Nada,

Thanks!
- gabor

-Nada

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 6 Sep 2007 15:38:27 -0400

Hi Nada,

Nice job! This gives a very good push to the transport section.

In order to capture the very last discussion, I'd suggest adding the
following text to the end of section 6.4:

"Also, retransmitting at the MIHF by using UDP in combination with MIH
acknowledgements allows having a better control and knowledge of these
retransmissions. For instance, in case of retransmitting ES messages
such as measurements, the MIHF could decide whether to retransmit the
same old measurement information or to transmit an updated measurement
in case that this new measurement is already available."

I'll take a detailed look at the slides and send comments if I have any.

Cheers,

Jc

-----Original Message-----
From: Nada Golmie [mailto:[email-masked]] 
Sent: September 6, 2007 1:44 PM
To: Zuniga, Juan Carlos; [email-masked]; [email-masked]
Subject: Text for Section 6 + Simulation results

Hello All,

study:

multiple routes in order to take advantage of SCTP's multi-homing
features.

Best wishes,

-Nada

>> Gabor: When discovery happens, the MN decides where it wants to
perform
>> -- Add a 4.3 section describing the collocation of services beyond
what
to 
>> + JCZ -- add a paragraph in section 3 about co-location of the
mobility
>> + Subir-- to revise 4.1 according to the comment above Nada --
provide

---

From: <[email-masked]>
Date: Thu, 6 Sep 2007 16:29:22 -0500

Yes, very comprehensive text from Nada, thanks. The only comment I have
is that in section 6.6 you say that for IS tcp should be used if the
message is larger than the mtu, otherwise udp. I think we can not choose
the transport of the same service based on the message size at the MIHF,
for many reasons. My suggestion is to recommend the usage of tcp for IS.
This means deleting ', as well as small IS messages' from the end of the
first paragraph, and deleting ', especially if these messages exceed the
MTU of the path to the destination' from the end of the second paragraph
of section 6.6

- gabor

-----Original Message-----
From: ext Zuniga, Juan Carlos
[mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 12:38 PM
To: Nada Golmie; Bajko Gabor (Nokia-SIR/MtView); [email-masked]
Subject: RE: Text for Section 6 + Simulation results

Hi Nada,

Cheers,

Jc

-----Original Message-----
From: Nada Golmie [mailto:[email-masked]]
Sent: September 6, 2007 1:44 PM
To: Zuniga, Juan Carlos; [email-masked]; [email-masked]
Subject: Text for Section 6 + Simulation results

Hello All,

study:

Best wishes,

-Nada

perform
what
to 
mobility
provide 

--
Nada Golmie, Ph.D. 
Manager, High Speed Network Technologies Group National Institute of
Standards and Technology 100 Bureau Dr. Stop 8920 Gaithersburg, MD 20899
Email: [email-masked]
Phone: (301) 975-4190
Fax:   (301) 590-0932
Web: http://w3.antd.nist.gov

---

From: Nada Golmie <[email-masked]>
Date: Thu, 06 Sep 2007 17:39:48 -0400

Sure, the intent is not to switch service per message. I agree w/ the 
suggested changes.

-Nada

[email-masked] wrote:
>> besides the faster retransmissions is that the MIH controls better
>>     
> these
>   
>> could decide whether to retransmit the same old information or it
>>     
> could
>   
>> obtain and analyze the results since we're not familar with the
>>     
> module.
>   
>>> Should discussion and comparison between UDP/TCP be added in the
>>>       
> text?
>   
>>> -- Gabor: DNSSEC is not widely used and the benefit is not clear.
>>>       
> It's 
>   
>>> use is questionable.
>>>
>>>
>>> Action points:
>>>

---

From: Subir Das <[email-masked]>
Date: Thu, 06 Sep 2007 21:51:50 -0400

Tele,
Pl. find my part along with some additional drawings and restructuring. 
I will
provide some additional texts on Section 8 tomorrow morning.

-Subir

Telemaco Melia wrote:
>>>>> It’s use is questionable.
>>>>>
>>>>>
>>>>> Action points:
>>>>>

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                       NEC
Intended status: Standards Track                                  S. Xia
Expires: January 25, 2008                                         Huawei
                                                               N. Golmie
                                                                    NIST
                                                                 H. Jang
                                                                 Samsung
                                                                  S. Das
                                                               Telcordia
                                                                G. Bajko
                                                                   Nokia
                                                              JC. Zuniga
                                                            InterDigital
                                                           July 24, 2007

              Mobility Services Transport Protocol Design
                   draft-xxx-mipshop-mstp-solution-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Melia, et al.           Expires January 25, 2008                [Page 1]

Internet-Draft                    MSTP                         July 2007

Abstract

   To be edited.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  3
   4.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  9
     4.2.  MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . .  9
   5.  MoS Discovery  . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  MoS Discovery in the home network  . . . . . . . . . . . .  9
     5.2.  MoS Discovery in the local network . . . . . . . . . . . . 10
     5.3.  MoS discovery in a remote network  . . . . . . . . . . . . 10
   6.  MIH Transport  . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Congestion Control . . . . . . . . . . . . . . . . . . . . 12
   7.  Operation Flows  . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     11.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 15

Melia, et al.           Expires January 25, 2008                [Page 2]

Internet-Draft                    MSTP                         July 2007

1.  Introduction

   This document proposes a solution to the issues indetified in the
   problem statement document [ref to PS] for the transport of IEEE
   802.21 MIH protocols.

   The MIH Layer 3 transport problem is divided in two main parts: the
   discovery of mobility services (MoS) and the transport of the
   information between MN and MoS.  The discovery process is required
   for MIH function located in the MN to discover the peer MIHF (e.g.
   the IP address) of the MoS in the network (e.g. the Point of Service,
   PoS) either during attachment or during handover.  Upon successfull
   discovery, the MIH peers can then exchange information in the form of
   MIH messages.

   This document considers firstly standard track IETF-based solutions
   for the design and recommendations of the discovery and transport
   protocol components.

2.  Terminology

   The following terminology is being used:

   MIH  Media Independent Handover

   MN Mobile Node

   NN Network Node

   MIHFID  MIH Identifier

   MIHF  MIH Function

   MoSh  Mobility Services at the Home Network

   MoSv  Mobility Services at the Visited Network

   MoS3  Mobility Services at a 3rd Party Network

3.  Deployment Scenarios

   The follwoing scenarios have been identified:

Melia, et al.           Expires January 25, 2008                [Page 3]

Internet-Draft                    MSTP                         July 2007

   S1 Home Network MoS, the MN and the services are located in the home
      network.  We refer to this as MoSh as in Figure 1.

   +--------------+  +====+
   | HOME NETWORK |  |MoSh|
   +--------------+  +====+
        /\
        ||
        \/
   +--------+
   |   MN   |
   +--------+

                      Figure 1: MoS in the Home network

   S2 Visisted Network MoS, MN is in the visited network and mobility
      services are also provided by the visited network.  We refer to
      this as MoSv Figure 2.

             +--------------+
             | HOME NETWORK |
             +--------------+
                   /\
                   ||
                   \/
    +====+ +-----------------+
    |MoSv| | VISITED NETWORK |
    +====+ +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

                    Figure 2: MoSV in the Visited Network

   S3 Roaming MoS, MN is in the visited network and all services are
      provided by the home network.

Melia, et al.           Expires January 25, 2008                [Page 4]

Internet-Draft                    MSTP                         July 2007

    +====+   +--------------+
    |MoSh|   | HOME NETWORK |
    +====+   +--------------+
                   /\
                   ||
                   \/
          +-----------------+
          | VISITED NETWORK |
          +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

             Figure 3: MoS provided by the home while in visited

   S4 Third party MoS, MN is in home or visited network and services are
      provided by a 3rd party network.  We refer to this as MoS3
      Figure 4.

      (preamble)
                                      +--------------+
                                      | HOME NETWORK |
   +====+    +--------------+         +--------------+
   |MoS3|    | THIRd PARTY  |  <===>        /\
   +====+    +--------------+               ||
                                            \/
                                    +-----------------+
                                    | VISITED NETWORK |
                                    +-----------------+
                                            /\
                                            ||
                                            \/
                                        +--------+
                                        |   MN   |
                                        +--------+

                       Figure 4: MoS form a third party

4.  Solution Overview

   As mentioned in the introduction the solution space is being divided
   in discovery and transport.  The follwoing assumptions have been
   made:

Melia, et al.           Expires January 25, 2008                [Page 5]

Internet-Draft                    MSTP                         July 2007

   o  The solution is aimed at supporting 802.21 MIH services, namely
      Information Services (IS), Event Services (ES), and Command
      Services (CS).

   o  If the MIHFID is available, FQDN or NAI's realm is used for
      mobility service discovery.  The recommentdation to the IEEE
      802.21 WG is to restrict to only these two.

   o  The solutions are choosen to cover all possible deployment
      scenarios as described in section 3.

   o  MIHF discovery can be performed during initial network attachment
      or thereafeter.

   For the discovering the location of an MoS, the MN could either be
   pre-configured with the address of the MoS, or this address could be
   dynamilcally assigned through DHCP or DNS by the network.  The
   dynamic assignation methods are described in section 5.

   The configuration of the MoS could be executed either upon network
   attachment or after succesfull IP configuration.  The methodology to
   be used depends on the considered deployment scenario.

Melia, et al.           Expires January 25, 2008                [Page 6]

Internet-Draft                    MSTP                         July 2007

    

    S4 can be supported only via DNS discovery.

   NOTE: add an example of how we intend to support discovery via DNS.

   Once the MIHF peer has been discovered, MIH information can be
   exchanged between peers over UDP and TCP.  The usage of these
   protocols is described in section 6.

Melia, et al.           Expires January 25, 2008                [Page 8]

Internet-Draft                    MSTP                         July 2007

4.1.  Reference Model

   The following figure depicts the MSTP reference model and its
   components within a node.

    +--------------------------+
    |           MIHF           |
    +--------------------------+
        ||         ||       ||
    +---------+ +------+ +-----+
    | TCP/UDP | | DHCP | | DNS |
    +---------+ +------+ +-----+

                            Figure 8: MN stack

   As it can be seen, the MIHF relies on the services provided by TCP
   and UDP for transport, as well as DHCP and DNS for peer discovery. 
   In cases where peer MIHF IP address is not preconfigured, source MIHF 
   needs to discover it either via DHCP  or DNS or using a combination 
   of both as described in Section 6. Once peer MIHF is discovered, MIHF 
   must exchange messages with its peer over either UDP or TCP. Specific 
   recommendations on choice of transport protocols are provided in Section 6.

   The above reference architecture however does not provide the model for 
   other services such as, fragmentation and security. Depending upon the MIH 
   services (e.g., ES, CS and IS) the message size can be very large. In 
   cases where underlying layer does not support fragmentation, this may be 
   an issue. There is no security available currently at the MIH protcol level.
   However, security can be provided either at the transport or IP 
   layer where it is necessary. Section 8 provides some guidelines and recommedations
   for security. 

4.2.  MIHF Identifiers (FQDN, NAI)

   An MIHID is an identifier required to uniquely identify the MIHF end
   points for delivering the mobility services (MoS).  Thus an MIHF
   identifier needs to be unique within a domain whereby mobility
   services are provided and invariant to interface IP addresses.  An
   MIHFID MUST be represented either in the form of an FQDN [REFERENCE]
   or NAI [REFERNCE].  An MIHFID can be pre-configured or discovered
   through the discovery methods as described in Section 5.

5.  MoS Discovery

   The MoS discovery method depends on whether the MN wants to discover
   an MoS in the local network, home network or a remote network other
   than home network.

5.1.  MoS Discovery in the Home Network

   To discover an MoS in the home network, the MN SHOULD use the DNS
   based MoS discovery method described in [draft-bajko-dns-discovery].
   In order to use that, the MN MUST first find out the domain name of
   its home network.  Home domains are usually preconfigured in the MNs,

Melia, et al.           Expires January 25, 2008                [Page 9]

Internet-Draft                    MSTP                         July 2007

   thus the MN can simply read its configuration data to find out the
   home domain name (scenario s1).

   Alternatively, the MN MAY use the dhcp options for MoS discovery
   [draft-bajko-dhcp-mos].  

   Following figure provides such model.

                           +-------+      
            +----+         |Domain |
            | MN |-------->|Name   | 
            +----+         |Server | 
                           +-------+ 
             [email-masked]

                          (a) using DNS Query

                         +-----+      +------+      
            +----+       |NAS/ |      |DHCP  | 
            | MN |<----->| DHCP|<---->|Server| 
            +----+       |Relay|      |      | 
                         +-----+      +------+ 

                          (b)  Using DHCP Option  

            Figure XX:  MOS Discovery (a) Using DNS query, (b) using DHCP option

5.2.  MoS Discovery in the Visited Network and Services are Local

   To discover an MoS in the visited network, the MN SHOULD
   attempt to use the dhcp options for MoS discovery
   [draft-bajko-dhcp-mos].   If the dhcp method fails, the MN SHOULD
   attempt to use the DNS based MoS discovery method described in
   [draft-bajko-dns-discovery].  In order to use that, the MN MUST first
   learn the domain name of the local network.  There are a number of
   ways how the domain name of a network can be learned:

   DHCP  In order to find out the domain name of the local network, the
      MN SHOULD use the dhcpv4 option 15 for learning the domain name
      [RFC1533].  Similar solution is available for dhcpv6
      [draft-ietf-dhc-dhcpv6-opt-dnsdomain].

   Reverse dns query  When dhcp does not provide the required domain
      name, the MN MAY use reverse dns (dns PTR record) to find the
      domain name associated with the IP address it is using in the
      local network.  Note, that when a NAT device exists between the MN
      and the local network, the MN will first need to find out the
      external IP address of the NAT device.  Some possible methods for
      determining the NAT's external IP address are STUN [RFC3489] or
      UPnP [UPnP_IDG_DCP].  Once the MN determined the external IP
      address of the NAT device, it MUST use that address in the reverse
      DNS query.

      Following figure provides such a model:

                         +-----+      +------+      
            +----+       |NAS/ |      |DHCP  | 
            | MN |<----->| DHCP|<---->|Server| 
            +----+       |Relay|      |      | 
                         +-----+      +------+ 

                   (a) MOS Discovery using DHCP options 

                           +-------+      
            +----+         |Domain |
            | MN |-------->|Name   | 
            +----+         |Server | 
                           +-------+ 

                    (b) Reverse DNS Query

                 Figure XX:  MOS Discovery (a) using DHCP option, (b) Using DNS reverse Query

5.3.  MOS Discovery in a roaming Network and Services are at Home 

   To discover an MoS in the roaming network when services are provided by the home network 
   MN SHOULD use the DHCP option along with network access authnetication (e.g. DHCP/AAA). 
   MN SHOULD use the dhcp options for MoS discovery
   [draft-bajko-dhcp-mos] immediately after the network access authentication. 

   Following figure describes the such a model:

                      Visited               |   Home
                                            |
                                            |
                        +-------+           |        +-------+
                        |       |           |        |       |

       AAAv -- Visited AAA
       AAAH -- Home AAA
       NAS  -- Network Access Server   

       Figure XX:  MOS Discovery using Network Access Authentication and DHCP options 

5.4 MoS discovery in a remote network

   To discover an MoS in a remote network other than home
   network, the MN MUST use the DNS based MoS discovery method described
   in [draft-bajko-dns-discovery].  In order to use that, the MN MUST
   first learn the domain name of the network it is looking for an MoS
   in.  If the MN does not yet know the domain name of the network,
   learning it may require more than one operation, as pre-configuration
   and dhcp can not be used.  The MN MAY attempt to first discover an
   MoS in either the local or home network and query that MoS to find
   out the domain name of a specific network or the domain name of a
   network at a specific location.  Alternatively, the MN MAY query an
   MoS previously known to learn the domain name of the desired network
   (e.g., via an IS Query).

   Following figure describes auch a model:

                           +-------+      
            +----+         |Domain |
            | MN |-------->|Name   | 
            +----+         |Server | 
                           +-------+ 
             [email-masked]

                 (a) using DNS Query

                           +------------+      
            +----+         |            |
            |    |         |Information |
            | MN |-------->| Server     |
            |    |         |(previously |
            +----+         |  Known)    |     
                           +------------+ 

                  (b) Using IS query 

    Figure XX:  MOS Discovery using (a) DNS Query, (b) IS Query to a known Server 

Melia, et al.           Expires January 25, 2008               [Page 10]

Internet-Draft                    MSTP                         July 2007

6.  MIH Transport

   Once the Mobility Services have been discovered, MIH peers MUST
   exchange information over TCP or UDP.  Both protocols provide a well
   proven transport for MIH messages.  There are advantages and
   disadvantages with using each one of them.  Therefore, some
   guidelines are hereby provided.

   As recommend in [draft-ietf-tsvwg-udp-guidelines-02.txt] an
   MIHFSHOULD NOT send UDP messages that result in IP packets that
   exceed the MTU of the path to the destination, and the UDP checksum
   option SHOULD be enabled.  Since ES ans CS messages are small in
   nature and have tight latency requirements, UDP in combination with
   MIH acknowledgement SHOULD be used for transporting ES and CS
   messages, as well as small IS messages.

   Also, as explained in [draft-ietf-tsvwg-udp-guidelines-02.txt],
   communication failures may be experienced when middleboxes destroy
   the per-flow state associated with an application session during
   periods when the application does not exchange any UDP traffic.
   Hence, communication between the MN and the MoS SHOULD be able to
   gracefully handle such failures and implement mechanisms to re-
   establish their UDP sessions.  In addtition and in order to avoid
   such failures, MIH messages MAY may be sent periodically, similarly
   to keep-alive messages, to attempt to refresh middlebox state (e.g.
   ES reports could be used for this purpose).  Unfortunately, no common
   timeout has been specified for per-flow UDP state for arbitrary
   middleboxes.  For NATs however, [RFC4787] requires a state timeout of
   2 minutes or longer, and it is likely that other types of middleboxes
   use timeouts of similar timescales.  Hence, MIH messages using UDP as
   traqnsport SHOULD be sent once every two minutes.

   On the other hand, IS messages are more resilent in terms of latency
   constraints and some long IS messages could exceed the MTU of the
   path to the destination.  Therefore, TCP SHOULD be used for
   transporting IS messages, especially if these messages exceed the MTU
   of the path to the destination.

   For both UDP and TCP cases, if a port number is not explicitly
   assigned (e.g. by the DNS SRV), MIH messages sent over UDP or TCP
   MUST use the default port number.

6.1.  Fragmentation

   NOTE JCZ: waiting for input from Nada

Melia, et al.           Expires January 25, 2008               [Page 11]

Internet-Draft                    MSTP                         July 2007

6.2.  Congestion Control

   NOTE JCZ: waiting for input from Nada

7.  Operation Flows

   NOTE: Include here flows for each of the scenarios we want to
   support.  Not yet assigned

                        MIH ENABLED MN
     +---------------+     +-------------+
     |  DHCP SERVER  |     | DHCP CLIENT |
     +---------------+     +------|------+
             |                    |
             |    DHCP DISCOVER   |
             |<===================|DHCP DISCOVER
             |                    |WITH MoS option
             |                    |
             |    DHCP OFFER      |
             |===================>|DHCP OFFER
             |                    |WITH MoS
             |   DHCP REQUEST     |
             |<===================|
             |     DHCPACK        |
             |===================>|
             |                    |

   Using DHCP 4-way handshake

                 Figure 5: Discovering MoS Function (MIHF)

   Upon layer-two network attachement the MN broadcasts DHCP DISCOVER
   messages according to standard [RFC 2132].  According to standard
   behavior the MN can wait to receive multiple replies from DHCP
   servers.  In any case the MN adds the MoS option to the discover
   message.  The DHCP offer message will then contain the IP address of
   the MoS.

                          MIH ENABLED MN
    +---------------+     +-------------+
    |  DHCP SERVER  |     | DHCP CLIENT |
    +---------------+     +------|------+
            |                    |
            |    DHCP INFORM     |
            |<===================|DHCP INFORM
            |                    |WITH MoS option
            |     DHCPACK        |
            |===================>|
            |                    |

   Using DHCP 2-way handshake

                 Figure 6: Discovering MoS Function (MIHF)

   Figure 6 shows the 2 way hanshake operation with MoS option enabled.

Melia, et al.           Expires January 25, 2008                [Page 7]

Internet-Draft                    MSTP                         July 2007

   For DHCPv6 based solutions we should distinguish between having
   stateless autoconfiguration and DHCP two messages based exchange or
   stateful configuration, thus four messages based exchange.  The
   follwoing figure shows how discovery of the MoS can be done through
   the first method.

   +--------------+     +--------------+
   |  DHCP CLIENT |     |  DHCP SERVER |
   +------|-------+     +-------|------+
          |                     |
          |                     |
          | INFORMATION-REQUEST |
          |====================>|
          |                     |
          |   REPLY             |
          |<====================|
          |                     |
          |                     |

                  Figure 7: DHCPv6 two messages exchange

   The INFORMATION REQUEST message is sent to the multicast FF02::1:2
   address containing an "Option Request" option.  Based on the "Client
   identifier" option the DHCP server can send a REPLY message including
   the option requested by the client.  In this case the option will
   refer to the MoS IP address being discovered.

   *** Should we add and informative flow for the case where the address is
   assigned via stateless autoconf? *** 

   Subir> I do not think we need such a scenario here...

   Figure (Figure 5) , figure (Figure 6)and figure (Figure 7) meets the
   requiremetns imposed by scenarios S1 and S2.  S3 needs tight
   interaction with the AAA infrastructure and figure 8 captures such a case.

   +-----------+        +----------------+   +----------+    +----------------+
   |    MN     |        |Access Gateway/ |   |  DHCP    |    |                |
   |DHCP Client|        |DHCP Relay      |   |  Server  |    |Home AAA Server |
   +----|------+        +------|---------+   +----|------+   +-------|--------+       
        |                      |                  |                  |
        | Access Authentication| Access Authentica|tion Request      |
        |  Request with NAI    | forwarded to Home| Domain           | 
        |=====================>|==================|=================>|                
        |                      |                  |                  |
        |                      | Access Autneticat|ion success       |
        |Authentication Success| with MoS informat|ion               |
        |<=====================|<=================|==================|
        |                      |                  |                  |
        |    DHCP DISCOVER     |                  |                  |            
        |  with MOS option     |                  |                  |
        |=====================>|=================>|                  |
        |                      |                  |                  |                       
        |    DHCP OFFER        |                  |                  |         
        | with MOS information |                  |                  |
        |<=====================|<=================|                  |
        |                      |                  |                  |
        |   DHCP REQUEST       |                  |                  |
        |======================|=================>|                  |              
        |                      |                  |                  |
        |   DHCPACK            |                  |                  |
        |<=====================|==================|                  |
        |                      |                  |                  |
        |                      |                  |                  |
 
       Figure 8: Discovering MoS Function (MIHF) coupled with Network 
                 Access Authentication 

   NOTE: add the picture for DHCP/AAA discovery.

8.  Security Considerations

   There are a number of security issues that need to be taken into
   account during node discovery and information exchange via a
   transport connection [refer PS draft].

   In case where DHCP is used for node discovery and authentication of
   the source and content of DHCP messages are required, it is
   receommended that network administrators should use DHCP
   authentication option described in RFC 3118 [DHCP Authentication].
   This will also protect the denial of service attacks to DHCP server.
   RFC 3118 provides mechanisms for both entity authentication and
   message authentication.

   In case where DNS is used for discovering the IP address of the MIHF
   and mobility services and data origin authentication and data
   integrity are required it is recommended that DNS service providers
   should use the Domain Name System Security Extensions (DNSSEC) as
   decsribed in RFC 4033 [DNSSEC].  Readers may also refer to RFC
   [DNSSEC Operational prcatice] to consider the aspects of DNSSEC
   Operational Practices. 

9.  IANA Considerations

   This document registers the following TCP and UDP port(s) with IANA:

   discard XXX/mih Discard YY:ZZZ

10.  Acknowledgements

   ....

11.  References

Melia, et al.           Expires January 25, 2008               [Page 12]

Internet-Draft                    MSTP                         July 2007

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [Anchor]   "", 2005.

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Phone:
   Fax:
   Email:
   URI:

   Sam Xia
   Huawei

   Phone:
   Fax:
   Email:
   URI:

   Nada Golmie
   NIST

   Phone:
   Fax:
   Email:
   URI:

Melia, et al.           Expires January 25, 2008               [Page 13]

Internet-Draft                    MSTP                         July 2007

   Heejin Jang
   Samsung

   Phone:
   Fax:
   Email:
   URI:

   Subir Das
   Telcordia

   Phone:
   Fax:
   Email:
   URI:

   Gabor Bajko
   Nokia

   Phone:
   Fax:
   Email:
   URI:

   Juan Carlos Zuniga
   InterDigital

   Phone:
   Fax:
   Email:
   URI:

Melia, et al.           Expires January 25, 2008               [Page 14]

Internet-Draft                    MSTP                         July 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Melia, et al.           Expires January 25, 2008               [Page 15]

---

From: Sam Xia <[email-masked]>
Date: Sat, 08 Sep 2007 17:19:34 +0800

Gabor

> -- Regarding Sam's 2.3
> Gabor: When discovery happens, the MN decides where it wants 
> to perform the discovery of mobility services. 

I know that when discovery happens, the MN decides where it wants to perform
the discovery of mobility services.  Do you mean that at the different
networks (visted networks), MN use different methods/technologis to
discovery?  I think that it is not good. I would prefer that we should unify
discovery mechanism.
I know that because DHCP can be used to discovery home MoS(AAA), local
visityed MoS and maybe the third party MoS, for example when MN is accessing
visited, how the DHCP server reply with the MoS MN desires? so it is very
useful and reasonable to add a DHCP option which help MN designate what MoS
is preferred.

---

From: Subir Das <[email-masked]>
Date: Mon, 10 Sep 2007 09:23:41 -0400

Folks,
While we will be investigating SCTP, do we also need to also investigate 
DCCP?

-Subir

---

From: Telemaco Melia <[email-masked]>
Date: Mon, 10 Sep 2007 17:15:14 +0200

We said we want to focus on standard track solutions.
What is the status of the 2 protocols?

tele

Subir Das wrote:
> Folks,
> While we will be investigating SCTP, do we also need to also 
> investigate DCCP?
>
> -Subir
>
>> [mailto:[email-masked]] Sent: Thursday, September 
>> 06, 2007 5:20 AM
>> To: [email-masked]
>>> It's use is questionable.
>>>
>>>
>>> Action points:
>>>
>>> provide + text for section 6 Tele/JCZ -- provide flows for section 7 
>>> Gabor -- + revise section 8
>>>
>>>

---

From: <[email-masked]>
Date: Mon, 10 Sep 2007 10:30:36 -0500

Both are standards track. 
For ES/CS we really need only a minor functionality from the transport, as those messages are very infrequent and small. 
Making some more analysis during the weekend, I again came to the conclusion that tcp would be the best for ES/CS too. The fact that the tcp retransmission timeout does not act fast enough is NOT a reason for using udp. There is no way one could design an application level retransmission which would have a faster reaction time than the tcp one.  There are some basic parameters in tcp, and one could play with those to make tcp act faster ...
And with tcp, middlebox traversal would not be an issue either.

The additional features of sctp and dccp over tcp are not likely to be utilised for ES/CS type of service transport anyway.

/gabor

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 8:15 AM
To: Subir Das
Cc: Bajko Gabor (Nokia-SIR/MtView); [email-masked]; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Short notes

tele

Subir Das wrote:
>> I just got word that SCTP uses the same retransmission timeout 
>> (200ms) as TCP. So probably running the simulations with SCTP would 
>> give exactly the same result as running it with TCP.
>>
>> - gabor
>>
>> Delays w/ TCP are mainly due to retransmissions in the case of 
>> network loss and congestion conditions.
>> <gabor> ok, I see. I think this should be pointed out in the draft. 
>> We also have to make sure that the MIH level ACK we use with UDP acts 
>>> + mobility

---

From: Subir Das <[email-masked]>
Date: Mon, 10 Sep 2007 14:26:24 -0400

Does this mean if we use TCP for all cases we can get rid of ACK?

-Subir

---

From: Subir Das <[email-masked]>
Date: Mon, 10 Sep 2007 14:27:04 -0400

Yes, both have RFC number and in Standards Track

Telemaco Melia wrote:
>>>> provide + text for section 6 Tele/JCZ -- provide flows for section 
>>>> 7 Gabor -- + revise section 8
>>>>
>>>>

---

From: <[email-masked]>
Date: Mon, 10 Sep 2007 13:37:46 -0500

Yes, that's a "side effect" of using tcp. 

- gabor

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 11:26 AM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: [email-masked]; [email-masked];
[email-masked]

-Subir

[email-masked] wrote:
> For ES/CS we really need only a minor functionality from the
transport, as those messages are very infrequent and small. 
> Making some more analysis during the weekend, I again came to the
conclusion that tcp would be the best for ES/CS too. The fact that the
tcp retransmission timeout does not act fast enough is NOT a reason for
using udp. There is no way one could design an application level
retransmission which would have a faster reaction time than the tcp one.
There are some basic parameters in tcp, and one could play with those to
make tcp act faster ...
> The additional features of sctp and dccp over tcp are not likely to be
utilised for ES/CS type of service transport anyway.
>>> We also have to make sure that the MIH level ACK we use with UDP 
>>> acts 'faster' than tcp in case of loss. In case of congestion, I 
>>> guess it doesn't make a difference.
>>>
>>>  
>>>       

module.

text?

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 11 Sep 2007 03:39:30 -0400

Gabor,

I would like to know what kind of analysis you made to come up to this
conclusion, as it seems to contradict the simulation analysis that we
have been using as baseline so far.

Besides, I agree that ES/CS are small(er than IS), but I would strongly
disagree with you when you consider ES/CS messages as infrequent. This
is exactly what we have been saying all the time for IS, but not for
ES/CS, which are much more dynamic and will be required in the most
critical part of the handover. You might claim that there are just a few
milliseconds in difference if we used TCP instead of UDP, but it is
these milliseconds which will make the whole difference.

Finally, remember that we are just recommending the use of TCP for IS
and UDP for ES/CS. This means that you could decide to implement
everything on TCP and you would still comply with the recommendation. If
other people decided to put more emphasis on ES/CS than IS, they could
also decide to implement everything on UDP. 

We are now reaching some consensus and we are finally doing good advance
in the DT. Please don't get hung up on the issue.

Regards,

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 2:38 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

- gabor

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 11:26 AM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: [email-masked]; [email-masked];
[email-masked]

-Subir

module.

text?

---

From: <[email-masked]>
Date: Tue, 11 Sep 2007 11:37:25 -0500

I do not intend to hung up on the issue, I just provided my technical
comments.
The term 'infrequency' was meant relative to a constant flow traffic,
where tcp empties cwnd one after the other. I still sustain
'infrequency' is a good characterization of the ES/CS traffic.

How many milliseconds you can gain is up to the initial value of RTO. If
a datagram consisted of many tcp segments, then tcp's other features may
have kicked in and retransmit a lost chunk faster. But ES/CS being one
tcp segment, adaptive rtt, fast retransmit, etc, will not even be used,
so there is not much to gain in retransmission when using tcp vs when
using udp. The main gain is that there is no middlebox issue when using
tcp.

Your mail may have suggested that you think you can gain a few
milliseconds when using udp vs using tcp. So this is wrong. You can not
gain absolutely nothing with an applic level retransmission vs tcp. TCP
has bunch of algorithms developed and tested over 30 years. What .21
retransmission is saying is that after 2 retransmissions you give up,
while tcp would never give up, but increase the RTO and keep
retransmitting. And we can not break I-D.ietf-tsvwg-udp-guidelines,
which clearly describes how to estimate the rtt and set rto.

> what kind of analysis you made to come up to this conclusion, as it
seems to contradict the simulation analysis that we have been using as
baseline

I spent many years working with tcp. For a traffic with less than 5 tcp
segments (remember: ES/CS is 1 tcp segment), I can calculate you how
long it takes to transfer those, with all kind of lost scenarios,
without any simulations.

- gabor

-----Original Message-----
From: ext Zuniga, Juan Carlos
[mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 12:40 AM
To: Bajko Gabor (Nokia-SIR/MtView); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

Gabor,

Regards,

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 10, 2007 2:38 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

- gabor

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]]
Sent: Monday, September 10, 2007 11:26 AM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: [email-masked]; [email-masked];
[email-masked]

-Subir

module.

text?

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 12 Sep 2007 04:23:25 -0400

Hi Gabor,

It looks like we are 'almost but not quite' talking about the same
thing.

I agree with your technical statements about TCP. However, when I say
that you gain time I meant it from the point of view of the
retransmission. As you say, MIH will give up faster than TCP, which
means that the MIH is aware of the problem and can react accordingly.
This is also related to the discussion about sending updated
measurements in case an old one does not make it through, etc.
Transmission will take the same time, but in case of retransmissions the
best information will get at the destination faster if we rely on
UDP+MIH/ACK.

Also, I used the term frequency from the point of view of the MIH (as
described in section 6.2), not from the point of view of the TCP cwnd.

Perhaps we can discuss this better over the teleconference.

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 12:37 PM
To: Zuniga, Juan Carlos; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

- gabor

-----Original Message-----

Gabor,

Regards,

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 10, 2007 2:38 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

- gabor

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]]
Sent: Monday, September 10, 2007 11:26 AM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: [email-masked]; [email-masked];
[email-masked]

-Subir

module.

text?

---

From: <[email-masked]>
Date: Wed, 12 Sep 2007 10:09:03 -0500

Yes, almost but not quite yet.

The fact that .21 has specified MIH ACK in a way that it retransmits 2
times, does not mean that it is any better than handling the same thing
at the transport level. That is basically a poor reproduction of
RFC3758, partial reliability for SCTP.

And the MIH 'intelligence' you are talking about is too artificial. A
pure MIH over SCTP would give you the same functionality, but better
performance.

And in addition, MIH ACK is bad because:
- Specifies redundant functionality present in transport
- Duplicates running code (and this hurts handheld devices)
- Makes application more complex
- Inferior in performance

But this is a discussion we should have in 802.21 perhaps.

>From the DT point of view, I am ok with using any transport. But not
using MIH ACK with any of the transports, meaning: use tcp when full
reliability is needed, use sctp when partial reliability is needed, use
udp when there is no reliability required.

- gabor

-----Original Message-----
Sent: Wednesday, September 12, 2007 1:23 AM

Hi Gabor,

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 11, 2007 12:37 PM
To: Zuniga, Juan Carlos; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

- gabor

-----Original Message-----

Gabor,

Regards,

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 10, 2007 2:38 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Short notes

- gabor

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]]
Sent: Monday, September 10, 2007 11:26 AM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: [email-masked]; [email-masked];
[email-masked]

-Subir

module.

text?