Subject: Re: RE: [MIPSHOP-MIH-DT] Work items breakdown

From: Heejin Jang <[email-masked]>
Date: Fri, 08 Jun 2007 08:04:44 +0000 (GMT)

Hi, folks.
Please see the inline.
 
- Regards, 
Heejin.
 
-----Original Message-----
From: Sam Xia [mailto:[email-masked]] 
Sent: Friday, June 08, 2007 3:43 PM
To: 'Stefano Faccin'; 'Telemaco Melia'
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Work items breakdown
 
Hi all,
 see the inline,
 
 Best Regards, Sam Xia 

> 
> Hello all,
> I have a couple of comments. 
> 
> I am not sure that making any specific discovery mechanism mandatory 
> would be a safe constraint. I would suggest that as result of the DT 
> we provide a recommended mechanism for discovery of MIHF. However, if 
> we want the result of the DT to be used by other fora, we need to make 
> sure that other solutions are possible (e.g. for a specific link layer 
> the MIHF address may be provided to the terminal through link-layer 
> specific mechanisms). There should be a clause in the DT design 
> document that indicates other mechanisms are possible, and that a 
> given one is recommended.
 
I am fine with this.
 
HJ> I'm fine with this, too. 
But the question is what's the difference between DHCP discovery &
MIHF discovery from the perspective of functionality? If we decide to 
make new discovery mechanism for MIHF, it should provide better or additional
fuctionality  than that of DHCP except the basic discovery functionality. Otherwise, we 
don't have to.
 
And I agree with Stefano's opinion that it is necessary to mention in 
the DT document that the existing solutions such as DHCP should
be allowed for an alternative way.
 
> 
> As for the establishment of SAs, I think it is safer to assume that 
> the MIHF is functionally separate from other network entities. In 
> fact, we have no control on how MIH will be deployed in other fora, 
> and therefore in order to allow the MIH solution to be applied to 
> various configurations/architectures, we need to provide flexibility.
> Therefore, the basic solution should consider two cases:
> - SAs established between the MN and the MIHF separately from any 
> other SAs the MN may already have
> -  no SA establishment (i.e. to cater for the case where the specific 
> architecture where MIH is deployed implements the MIHF in a logical 
> network node that already has an SA with the MN that can be re-used), 
> i.e. do not make the SA establishment mandatory Scenarios where 
> optimizations are introduced to address the cases Sam identifies can 
> be considered in a later phase, perhaps?
 
I think so.
 
Tele, Robert and other teamates,  how do you think about Stefano's and my comments?
 
> 
> 
> 
> 
> 
> 
> Hi Tele, all,
>  Thank you for your input.
> I think that it is very good that we should have consensus on the 
> designing principle (about discovering, transportation, 
> security)before discussing the assignment.  So, I have some comments 
> on the input from Tele. I wish that everyone can reply actively.
> please see the inline.
> 
> 
> > 
> > Dear all,
> > 
> > Here it goes my proposal.
> > After the presentation Robert did last meeting we agreed to the 
> > following main three areas:
> > - The layer split (MSTP)
> > - Node discovery and message routing
> 
> Until now, we have no rough consensus on the discovering 
> issue. The followings are my questions that are worthy of 
> discussing, as well as my comments.
> 
> a) Should we resort to the existing the protocols and states, 
> such as DHCP?
> I think that DHCP is a very good candidate for MIHF 
> discovering mechanism.
> But, in [design-consideration], it is mentioned that DHCP is 
> a possible candidate, but only be the most suitable for link 
> technologies where this is used as an address assginment 
> method. My suggenstion is that we can use DHCP as a mandatory 
> discovering mechanism though DHCP is not used to assign address.
> 
> b) if we aggree to design a new discovering mechanims, what 
> should it look like?
> If the discovering mechanism looks like the DHCP and the 
> solution is deployed only in the access networks, not deep 
> into the core network or remote network,  why do we have to 
> design this solution instead of DHCP?
> If the discovering mechanism looks like the GIST and can be 
> deployed from the access network to core network (a lot of 
> routers are required to implement it), can we take so much 
> expense only for discovering service?
> Even the GIST-alike solution can be deployed only in the 
> access network, do we have any other reasons to adopt so 
> complicated discoverying mechanism?
> 
> > - Security and resilience
> > 
> > I would keep the same working areas and explore sub items as follow.
> > 
> > About MSTP the following issues were identified:
> > - identifiers of MSTP users (related to the 802.21 MIHFID)
> > - implication of the discovery mechanisms
> > - attributes of the message transfer
> > Additionally in the PS doc the following requirements are 
> related to 
> > attributes configuration:
> > - low latency
> > - reliability
> > - congestion control
> > - multiplexing
> > - multihoming
> > - v6/v4 support (including NAT/firewall traversal)
> 
> Before we discuss the above items, i think we should consider 
> the following
> questions:
> 
> What is the base protocol for MIHF transportation? Is it 
> TCP/UDP/SCTP/raw socket, or the compound of them?
> 
> Can we use different transportation protocol in order to 
> meeting with the different attributes just as GIST does?
> 
> > 
> > About Node discovery and message routing we need to 
> identify scenarios 
> > (the PS just says what are the properties).
> > We did not discuss about this yet and I believe this is the most 
> > critical part of the whole problem.
> > 
> > About security the PS identifies:
> > - information from a trusted source
> > - security association management
> > - secure delivery
> 
> Before we discuss the above the security issues, it is worthy 
> of discussing the following:
> 
> What is our choice between TLS and IPSec, or something else?
> 
> I am sure that the security protocol can solve the 
> authentication issue(information from a trusted source).
> 
> As to the SA manangement, I think that we have to spend much 
> time on this point. As we all know, there are  a lot of SAs 
> between MN and the network entity in the network side, such 
> as the SA between MN and Home Agent, the SA between MN and 
> AAA/authenticator/AP(discussed in HOKEY). My question is that 
> whether we should create a new SA between MIHFs in MN and in 
> network entity, independent of the said-above SAs or 
> correlated with them?
> 
> If we use security protocol, I don't think secure delivery is 
> a problem.
> 
> 
> 
> > 
> > Would the breakdown help in solving the problems?
> > Let's fix this and then discuss assignments.
> > 
> > Let me know asap.
> > telemaco
> > 
> > _______________________________________________
> > MIPSHOP-MIH-DT mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> > 
> 
> 
> 

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

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

---

From: Sam Xia <[email-masked]>
Date: Fri, 08 Jun 2007 16:48:22 +0800

hi Heejin,

 Best Regards, Sam Xia 

> From: Heejin Jang [mailto:[email-masked]] 
> Sent: Friday, June 08, 2007 4:05 PM
> To: Sam Xia
> Cc: 'Stefano Faccin'; 'Telemaco Melia'; [email-masked]
> Subject: Re: RE: [MIPSHOP-MIH-DT] Work items breakdown
> 
> 
> Hi, folks.
> Please see the inline.
>  
> - Regards,
> Heejin.
>  
> But the question is what's the difference between DHCP 
> discovery & MIHF discovery from the perspective of 
> functionality? If we decide to make new discovery mechanism 
> for MIHF, it should provide better or additional fuctionality 
>  than that of DHCP except the basic discovery functionality. 
> Otherwise, we don't have to.

I don't think that there is difference between DHCP discovery and MIHF
discovery. 

See Clause 8.2 in [DRAFT802.21]:
MIH fuction discovery (Layer 2 only): The MIHF in a mobile node or in the
network discoverys which entity in the access networks supports an MIHF.

And i think DHCP can serve as the same role just as defined by .21.

Do you mean the difference between DHCP discovery and MIHF capability
discovery? DHCP can not be used to solve the capability discovery.

>  
> And I agree with Stefano's opinion that it is necessary to 
> mention in the DT document that the existing solutions such 
> as DHCP should be allowed for an alternative way.
>  
> > 
> > Until now, we have no rough consensus on the discovering issue. The 
> > followings are my questions that are worthy of discussing, 
> as well as 
> > my comments.
> > 
> > a) Should we resort to the existing the protocols and 
> states, such as 
> > DHCP?
> > I think that DHCP is a very good candidate for MIHF discovering 
> > mechanism.
> > But, in [design-consideration], it is mentioned that DHCP is a 
> > possible candidate, but only be the most suitable for link 
> > technologies where this is used as an address assginment method. My 
> > suggenstion is that we can use DHCP as a mandatory discovering 
> > mechanism though DHCP is not used to assign address.
> > 
> should it 
> > look like?
> solution is 
> > deployed only in the access networks, not deep into the 
> core network 
> > or remote network,  why do we have to design this solution 
> instead of 
> > DHCP?
> deployed 
> > from the access network to core network (a lot of routers 
> are required 
> > to implement it), can we take so much expense only for discovering 
> > service?
> > Even the GIST-alike solution can be deployed only in the access 
> > network, do we have any other reasons to adopt so complicated 
> > discoverying mechanism?
> > 
> > > - attributes of the message transfer Additionally in the 
> PS doc the 
> > > following requirements are
> > related to
> > Before we discuss the above items, i think we should consider the 
> > following
> > questions:
> > 
> meeting with 
> > the different attributes just as GIST does?
> > 
> > > 
> > Before we discuss the above the security issues, it is worthy of 
> > discussing the following:
> > 
> > I am sure that the security protocol can solve the authentication 
> > issue(information from a trusted source).
> > 
> > As to the SA manangement, I think that we have to spend 
> much time on 
> > this point. As we all know, there are  a lot of SAs between 
> MN and the 
> > network entity in the network side, such as the SA between 
> MN and Home 
> > Agent, the SA between MN and AAA/authenticator/AP(discussed 
> in HOKEY). 
> > My question is that whether we should create a new SA 
> between MIHFs in 
> > MN and in network entity, independent of the said-above SAs or 
> > correlated with them?
> > 
> > If we use security protocol, I don't think secure delivery is a 
> > problem.
> > 
> > 
> > 
> > >