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

From: Heejin Jang <[email-masked]>
Date: Fri, 15 Jun 2007 07:39:37 +0000 (GMT)

Hi, Tele.
I'd like to contribute on section 3, too.
And I think that Supported Scenarios needs to be described ASAP to give more concrete
concept for the following sections. 
 
ps> Since some of 21 folks are on the buz trip for 802.21 ad-hoc meeting,
it might be difficult to give a realtime answer even though they want to contribute on section 4. :-)
 
- Regards, 
Heejin.

------- Original Message -------
Sender : [email-masked]<[email-masked]>
Date   : 2007-06-14 08:50
Title  : RE: [MIPSHOP-MIH-DT] Work items breakdown

this looks OK to me.  I can also contribute to the Security
Considerations as well.

John 

>-----Original Message-----
>From: ext Telemaco Melia [mailto:[email-masked]] 
>Sent: 11 June, 2007 05:16
>To: Loughney John (Nokia-NRC/PaloAlto)
>Cc: [email-masked]
>Subject: Re: [MIPSHOP-MIH-DT] Work items breakdown
>
>Hi John,
>
>Here it goes. I started to associate names to sections based 
>on recent discussions but I would like to know your opinion.
>As for the discovery thread I am drawing a couple of pictures 
>to capture the options described so far.
>
>Views?
>tele
>
>
>[email-masked] wrote:
>> Telemaco,
>>
>> The topics below look like a ToC (nearly).  Shall we just jump into 
>> constructing a document, and assign pieces of it to DT members?
>>
>> I would suggest that you create a ToC and we start filling 
>it out, and 
>> if some places are still under discussion, we capture the discussion 
>> in the draft and continue the discussions on the WG mailing list.
>>
>> John
>>
>>   
>>> -----Original Message-----
>>> From: ext Telemaco Melia [mailto:[email-masked]]
>>> Sent: 06 June, 2007 09:34
>>> To: [email-masked]
>>> Subject: [MIPSHOP-MIH-DT] Work items breakdown
>>>
>>> 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
>>> - 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)
>>>
>>> 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
>>>
>>> Would the breakdown help in solving the problems?
>>> Let&#39;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: Telemaco Melia <[email-masked]>
Date: Fri, 15 Jun 2007 09:47:02 +0200

OK.
I am planning to have a first draft of the section on Monday/Tuesday.
We can use this as a base for discussions. It is ok?

tele

-- 
Dr. Telemaco Melia			[email-masked]
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.				Fax: +49 (0) 6221 4342- 155
Network Laboratories			Web: http://www.netlab.nec.de
Kurfuersten-Anlage 36			       
69115 Heidelberg
GERMANY   

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

---

From: "sam xia" <[email-masked]>
Date: Wed, 20 Jun 2007 00:18:42 +0800

Could i see the first draft you said?

BestRegards;
Sam(Zhongqi)Xia; 

  _____  

From: Telemaco Melia [mailto:[email-masked]] 
Sent: Friday, June 15, 2007 3:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Work items breakdown

OK.

tele

Heejin Jang wrote: 

Hi, Tele.

And I think that Supported Scenarios needs to be described ASAP to give more
concrete

it might be difficult to give a realtime answer even though they want to
contribute on section 4. :-)

- Regards, 

Heejin.

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

Sender : [email-masked] <mailto:[email-masked]>
<[email-masked]>

Date   : 2007-06-14 08:50

Considerations as well.

John 

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

Hi John,

Views?

tele

Telemaco,

it out, and 

John

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

Dear all,

- The layer split (MSTP)

related to 

- low latency

- reliability

- congestion control

- multiplexing

- multihoming

- secure delivery

Let me know asap.

telemaco

[email-masked]

    

[email-masked]

  

-- 

Kurfuersten-Anlage 36			       

69115 Heidelberg

GERMANY   

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
W3 6BL | Registered in England 2832014 
_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 19 Jun 2007 18:27:09 +0200

Hi Sam,

I started to write down ideas. I did not get where I wanted with the 
text but we can build discussions.
Please comment it.

tele

sam xia wrote:
> ------------------------------------------------------------------------
> *From:* Telemaco Melia [mailto:[email-masked]]
> *Sent:* Friday, June 15, 2007 3:47 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [MIPSHOP-MIH-DT] Work items breakdown
>
> OK.

Mipshop WG                                                    R. Hancock
Internet-Draft                                       Siemens Roque Manor
Intended status: Standards Track                           T. Melia, Ed.
Expires: December 13, 2007                                           NEC
                                                                  S. Xia
                                                                  Huawei
                                                             J. Loughney
                                                                   Nokia
                                                                 H. Jang
                                                                 Samsung
                                                                  S. Das
                                                               Telcordia
                                                           S. Sreematula
                                                                   Nokia
                                                              JC. Zuniga
                                                            Interdigital
                                                           June 11, 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 December 13, 2007.

Copyright Notice

Hancock, et al.         Expires December 13, 2007               [Page 1]

Internet-Draft                    MSTP                         June 2007

   Copyright (C) The IETF Trust (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.  Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Node Discovery and message routing  . . . . . . . . . . . . . . 3
     3.1.  Supported Scenarios . . . . . . . . . . . . . . . . . . . . 3
     3.2.  Implications on the MSTP  . . . . . . . . . . . . . . . . . 5
   4.  The layer split . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  Identifiers of MSTP users . . . . . . . . . . . . . . . . . 5
     4.2.  Attributes of the message transfer  . . . . . . . . . . . . 5
       4.2.1.  Low latency . . . . . . . . . . . . . . . . . . . . . . 5
       4.2.2.  Reliability . . . . . . . . . . . . . . . . . . . . . . 5
       4.2.3.  Congestion control  . . . . . . . . . . . . . . . . . . 5
       4.2.4.  Multiplexing  . . . . . . . . . . . . . . . . . . . . . 5
       4.2.5.  Multihoming . . . . . . . . . . . . . . . . . . . . . . 5
       4.2.6.  v4/v6 support . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security and Resilience . . . . . . . . . . . . . . . . . . . . 6
     5.1.  Information from a trusted source . . . . . . . . . . . . . 6
     5.2.  Security association management . . . . . . . . . . . . . . 6
     5.3.  Secure delivery . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

Hancock, et al.         Expires December 13, 2007               [Page 2]

Internet-Draft                    MSTP                         June 2007

1.  Introduction

   Introduce the document, its structure and scope of the solution.

2.  Solution Overview

3.  Node Discovery and message routing

   This section describes the considered scenarios for nodes discovery
   supporting MoS as specified in the PS [add ref] document.  The
   section furhter includes applicability scenarios considerations
   coming from other standardization fora considering such scenarios for
   potential deployment.

   It should be noted that according to the IEEE 802.21 draft standard
   the possible MoS are IS, ES and CS.  The DT believes that the
   location of such services (either in the home or in the visited
   network) imposes requirements on the design of the transport
   solution.  Specifically while IS is considered to efficiently
   operates in the visited network, ES nad CS services are more suited
   to home networks aiming at controlling node's mobility across
   heterogeneous networks.  In general we infer that the solution should
   accomodate both cases.

3.1.  Supported Scenarios

   The following scenarios have been identified:

      MoS supported in the home: the home network offers a complete set
      of MoS to mobile subscribers

      Mos supported in the visited and partially in the home: some of
      the MoS are located in the visited network and some of them in the
      home network.  Relation between the involved MoS is possible.

   The first one identifies the case where the home network supports any
   kind of MoS (e.g.  ES, CS, IS) as depicted in (Figure 1).  In this
   case the discovery of MoS can be based on preconfigured (statically)
   values.  Alternatively, with some technologies, parameters can be
   transferred via IP configuration methods upon gaining network access
   (e.g. in case of GPRS network).

Hancock, et al.         Expires December 13, 2007               [Page 3]

Internet-Draft                    MSTP                         June 2007

   MoS supported in the home
    +--------------+  +====+
    | HOME NETWORK |  |MoSh|
    +--------------+  +====+
          /\
          ||
          \/
      +--------+
      |   MN   |
      +--------+
   Traffic for MoS discovery back to the home

                     Figure 1: MoS located in the Home

   The second case considers MN attached to the visited network
   receiving MoS partially from the visited network and patrially from
   the home network (see Figure 2).  We should stress the fact that
   while discovery of the MoS in the visited network can be carried out
   via IP configuration methods, a different solution is required to
   tranport to the MN information about the MoS in the home network.

   MoS located in both networks

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

   MoSv (IS) MoSh (ES,CS)

                            Figure 2: MoS split

   As mentioned before when considereing mixed (home and visited)
   scenarios we should understand where MoS are located.

Hancock, et al.         Expires December 13, 2007               [Page 4]

Internet-Draft                    MSTP                         June 2007

                                (preamble)

                       +------+------+------+------+
                       |      | IS   | ES   | CS   |
                       +------+------+------+------+
                       | MoSh | X(p) | X    | X    |
                       | MoSv | X    | X(p) | X(p) |
                       +------+------+------+------+

                                (postamble)

   The previous table shows the possible location of the MoS and their
   preferred location within the home and visited.

   Since IS is accessible also when the MN is not authenticated in the
   network (see 802.21 draft) it makes sense to have the service in the
   visited.  With respect to ES and CS since the home network might want
   to keep control of the MNs it is more desirable to have both in the
   home network.  We should still discuss cases where the visited
   manages mobility (roaming scenarios) on behalf of the home (level of
   roaming agreements to be discussed).

3.2.  Implications on the MSTP

4.  The layer split

   Subir, JC

4.1.  Identifiers of MSTP users

4.2.  Attributes of the message transfer

4.2.1.  Low latency

4.2.2.  Reliability

4.2.3.  Congestion control

4.2.4.  Multiplexing

4.2.5.  Multihoming

4.2.6.  v4/v6 support

Hancock, et al.         Expires December 13, 2007               [Page 5]

Internet-Draft                    MSTP                         June 2007

5.  Security and Resilience

   Sam, other volunteers?

5.1.  Information from a trusted source

5.2.  Security association management

5.3.  Secure delivery

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

7.  Security Considerations

8.  Acknowledgements

9.  Normative References

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

Authors' Addresses

   Robert Hancock
   Siemens Roque Manor

   Phone:
   Fax:
   Email:
   URI:

Hancock, et al.         Expires December 13, 2007               [Page 6]

Internet-Draft                    MSTP                         June 2007

   Telemaco Melia (editor)
   NEC

   Phone:
   Fax:
   Email:
   URI:

   Sam Xia
   Huawei

   Phone:
   Fax:
   Email:
   URI:

   John Loughney
   Nokia

   Phone:
   Fax:
   Email:
   URI:

   Heejin Jang
   Samsung

   Phone:
   Fax:
   Email:
   URI:

Hancock, et al.         Expires December 13, 2007               [Page 7]

Internet-Draft                    MSTP                         June 2007

   Subir Das
   Telcordia

   Phone:
   Fax:
   Email:
   URI:

   Srinivas Sreematula
   Nokia

   Phone:
   Fax:
   Email:
   URI:

   Juan Carlos Zuniga
   Interdigital

   Phone:
   Fax:
   Email:
   URI:

Hancock, et al.         Expires December 13, 2007               [Page 8]

Internet-Draft                    MSTP                         June 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).

Hancock, et al.         Expires December 13, 2007               [Page 9]

---

From: Subir Das <[email-masked]>
Date: Wed, 20 Jun 2007 12:05:18 -0400

Sorry folks..  seems DT mailing list is very active now.. last two weeks
were very hectic for .21 related things.. did you already distribute the
first draft?

-Subir

---

From: Subir Das <[email-masked]>
Date: Wed, 20 Jun 2007 12:06:45 -0400

Ok, now I see your first draft.. will go over it and
give my input..

-Subir

---

From: Subir Das <[email-masked]>
Date: Wed, 20 Jun 2007 14:07:40 -0400

I just finished reading the DT thread and will start my comments with 
the discovery
and message routing first:

-- When we say node discovery, what are we discovering?

Is it the ID e.g., MIHF ID as defined by .21) of MOS?
Is it the transport address of MOS?
Is it the services provided by MoS? or
All of the above?

Regarding the scenario, I do not think we should make assumptions that 
only IS is
provided by the visited network. It is possible to provide all services 
either by the
home network or by the visited network or by a combination of both 
networks. Also
under Section "Supported Scenario" are we planning to depict all possible
architectures/deployment scenarios"?

Regarding discovery, my understanding is that Mipshop is responsible for 
providing solution
at L3 and above. L2 discovery is provided by the media specific 
technologies. For example,
802.11u defines for .11 and 802.16g defines for .16e.

Regarding message routing, is the objective to route only discovery 
message or other MOS
related messages as well?

-Subir

---

From: "sam xia" <[email-masked]>
Date: Thu, 21 Jun 2007 22:31:11 +0800

hi subir,
please see my comments inline.
-----Original Message-----
From: Subir Das [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 2:08 AM
To: Telemaco Melia
Cc: sam xia; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Work items breakdown

I just finished reading the DT thread and will start my comments with the
discovery and message routing first:

Sam> I prefer to what we are discovering is the transport address of MoS.
Why?  I don't think that it is good idea to discover only a MIHF ID because
we have to introduce another   
           mapping procedure from MIHF ID to the transportation address.
Here, another question is arisen that how to generate the MIHF ID based on
the transportation address. Just
          as .21 specified, FQDN and NAI can be MIHF ID, it is very good
that the providers of MoS have FQDN so that we discover the FQDN of MoS
while we discover the transportaiton 
          address of MoS. But what about the situation wherein there is no
FQDN for MoS? (this situation is very common). MIHF ID is necessary for .21
so that MIHF protocol can be 
         seperated from the bottom transportation protocol.
          I don't think that discovering the service provided by MoS is very
useful and enough.

Regarding the scenario, I do not think we should make assumptions that only
IS is provided by the visited network. It is possible to provide all
services either by the home network or by the visited network or by a
combination of both networks. Also under Section "Supported Scenario" are we
planning to depict all possible archi tectures/deployment scenarios"?

Sam> I agree with you.  In fact, I am thinking another possible scenario
wherein IS is deployed independent of the visiting network and homenetwork,
but nearby the visiting network. 
            I think that this scenario is useful for prevent cheating from
the visiting network. for example, mobile node is discovering another
network which is very low price than the 
           current access visiting network. But the IS in the visiting
network maybe cheat the mobile node and tell it that the price is very high.

Regarding discovery, my understanding is that Mipshop is responsible for
providing solution at L3 and above. L2 discovery is provided by the media
specific technologies. For example, 802.11u defines for .11 and 802.16g
defines for .16e.

Regarding message routing, is the objective to route only discovery message
or other MOS related messages as well?

-Subir

Telemaco Melia wrote:
>>> And I think that Supported Scenarios needs to be described ASAP to 
>>> give more concrete concept for the following sections.
>>>  
>>> ps> Since some of 21 folks are on the buz trip for 802.21 ad-hoc 
>>> ps> meeting,
>>>> Here it goes. I started to associate names to sections based on 
>>>> recent discussions but I would like to know your opinion.
>>>> As for the discovery thread I am drawing a couple of pictures to 
>>>> capture the options described so far.
>>>>
>>>> Views?
>>>> tele
>>>>
>>>>
>>>>> The topics below look like a ToC (nearly).  Shall we just jump 
>>>>> into constructing a document, and assign pieces of it to DT members?
>>>>>
>>>>> if some places are still under discussion, we capture the 
>>>>> discussion in the draft and continue the discussions on the WG mailing
list.
>>>>>> - attributes of the message transfer Additionally in the PS doc 
>>>>>> the following requirements are
>>>>>>         
>>>> related to
>>>>     
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
>> London W3 6BL | Registered in England 2832014
>
>
> -- 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
> London W3 6BL | Registered in England 2832014
>                                                            June 11, 
> 2007

---

From: Subir Das <[email-masked]>
Date: Thu, 21 Jun 2007 11:03:37 -0400

Sam,
So are you saying that, we need to discover MIHF ID and transport
address but no service capability? The reason I asked this question
is .21 defines both function discovery and capability discovery. I was
trying to understand our scope here.

Thanks,
-Subir

---

From: "sam xia" <[email-masked]>
Date: Thu, 21 Jun 2007 23:18:32 +0800

yes. we need to discover MIHF ID and transport address.  
And i think the capability discovering should be performed by MIHF protocol
itself, not by the transportation protocol. 

BestRegards;
Sam(Zhongqi)Xia;
-----Original Message-----
From: Subir Das [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 11:04 PM
To: sam xia
Cc: 'Telemaco Melia'; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Work items breakdown

Sam,
So are you saying that, we need to discover MIHF ID and transport address
but no service capability? The reason I asked this question is .21 defines
both function discovery and capability discovery. I was trying to understand
our scope here.

Thanks,
-Subir

sam xia wrote:
> the discovery and message routing first:
>
> Is it the services provided by MoS? or All of the above?
>
> Here, another question is arisen that how to generate the MIHF ID 
> based on the transportation address. Just
>           as .21 specified, FQDN and NAI can be MIHF ID, it is very 
> good that the providers of MoS have FQDN so that we discover the FQDN 
> of MoS while we discover the transportaiton
>           address of MoS. But what about the situation wherein there 
> is no FQDN for MoS? (this situation is very common). MIHF ID is 
> necessary for .21 so that MIHF protocol can be
>           I don't think that discovering the service provided by MoS 
> is very useful and enough.
>
> only IS is provided by the visited network. It is possible to provide 
> all services either by the home network or by the visited network or 
> by a combination of both networks. Also under Section "Supported 
> Scenario" are we planning to depict all possible archi tectures/deployment
scenarios"?
>
> Sam> I agree with you.  In fact, I am thinking another possible 
> Sam> scenario
> wherein IS is deployed independent of the visiting network and 
> homenetwork, but nearby the visiting network.
>             I think that this scenario is useful for prevent cheating 
> from the visiting network. for example, mobile node is discovering 
> another network which is very low price than the
> Regarding discovery, my understanding is that Mipshop is responsible 
> for providing solution at L3 and above. L2 discovery is provided by 
> the media specific technologies. For example, 802.11u defines for .11 
> and 802.16g defines for .16e.
>
> message or other MOS related messages as well?
>
> -Subir
>
> Telemaco Melia wrote:
>   
>> Hi Sam,
>>
>>> --------------------------------------------------------------------
>>> -
>>> ---
>> ---------------------------------------------------------------------
>> -
>> --
>>
>>
>>
>>
>> Mipshop WG                                                    R. Hancock
>> ---------------------------------------------------------------------
>> -
>> --
>>

---

From: <[email-masked]>
Date: Thu, 21 Jun 2007 10:29:46 -0500

Sam,

>And i think the capability discovering should be performed by 
>MIHF protocol itself, not by the transportation protocol. 

Just out of curiousity, can you explain why you think it should be
done by the protocol?

John

---

From: "sam xia" <[email-masked]>
Date: Thu, 21 Jun 2007 23:49:44 +0800

One thing is to decouple the transportation protocol from the MIHF protocol.
Otherwise, the transportation protocol needs  to read the content of payload
to be transported.
the other is that capability discovery require a sesscion between MIHF peers
while service discovery does not, unless that we save the capability of MIHF
into another database other than MIHF peer itself.

BestRegards;
Sam(Zhongqi)Xia;
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 11:30 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Work items breakdown

Sam,

>And i think the capability discovering should be performed by MIHF 
>protocol itself, not by the transportation protocol.

Just out of curiousity, can you explain why you think it should be done by
the protocol?

John

---

From: Subir Das <[email-masked]>
Date: Thu, 21 Jun 2007 14:27:58 -0400

I am understanding your point here.  Can you elaborate little more?

-Subir

sam xia wrote:
>> Why?  I don't think that it is good idea to discover only a MIHF ID
>>     
> because
>   
>> network maybe cheat the mobile node and tell it that the price is very
>>     
> high.
>   
>>>> Network Laboratories			Web:
>>>>         
> http://www.netlab.nec.de
>   
>>>> Kurfuersten-Anlage 36			       
>>>> 69115 Heidelberg
>>>> GERMANY   
>>>>

---

From: Subir Das <[email-masked]>
Date: Thu, 21 Jun 2007 14:36:16 -0400

I am little bit confused here.  Without a transport protocol, MoS or 
MIHF  protocol can not
function. Now what are we discovering? Even if we discover transport 
address that is
meant for MoS or MIHF protocol. So essentially, we are discovering MIHF 
transport
address.  So I do not understand the separation. Also what do you mean 
by service discovery?
What is the difference between service and capability discovery?

-Subir