Subject: [MIPSHOP-MIH-DT] FW: [Mipshop] Soliciting agenda items for MIPSHOP WG meeting at IETF68

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 1 Mar 2007 09:58:23 -0000

folks,

i would plan to ask vijay for 15-20 minutes on Thursday to report from
the DT. that should give us time to do some work during the week, as
well as whatever we do beforehand. any views?

also, who is actually coming and when are they arriving? it would be
interesting to see what mutually free times we have.

from the latest list of registrations:

    * heejin.jang at samsung.com [?]
    * john.loughney at nokia.com [?]
    * juancarlos.zuniga at interdigital.com [?]
    * robert.hancock at roke.co.uk [yes, but not yet registered...]
    * smfaccin at marvell.com [yes]
    * srinivas.sreemanthula at nokia.com [?]
    * subir at research.telcordia.com [yes]
    * telemaco.melia at netlab.nec.de [yes]
    * vijay.devarapalli at azairenet.com [yes]
    * xiazhongqi at huawei.com [yes]

r.

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: 01 March 2007 02:12
To: [email-masked]
Subject: [Mipshop] Soliciting agenda items for MIPSHOP WG meeting at
IETF68

Hello folks,

If you need a slot on the MIPSHOP agenda, please send a request to the
chairs.

Please mention the I-D name, and the amount of time you want.

MIPSHOP has two sessions at IETF 68.

TUESDAY, March 20, 2007, 1300-1500 Afternoon Session I THURSDAY, March
22, 2007, 1510-1610 Afternoon Session II

Vijay

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

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

---

From: Sam Xia <[email-masked]>
Date: Thu, 01 Mar 2007 19:20:53 +0800

hi all,
 I am sure I will attend this meeting.

 Best Regards, Sam Xia 

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Thursday, March 01, 2007 5:58 PM
> To: [email-masked]
> Subject: [MIPSHOP-MIH-DT] FW: [Mipshop] Soliciting agenda 
> items for MIPSHOP WG meeting at IETF68
> 
> folks,
> 
> i would plan to ask vijay for 15-20 minutes on Thursday to 
> report from the DT. that should give us time to do some work 
> during the week, as well as whatever we do beforehand. any views?
> 
> also, who is actually coming and when are they arriving? it 
> would be interesting to see what mutually free times we have.
> 
> If you need a slot on the MIPSHOP agenda, please send a 
> request to the chairs.
> 
> TUESDAY, March 20, 2007, 1300-1500 Afternoon Session I 
> THURSDAY, March 22, 2007, 1510-1610 Afternoon Session II
> 
> Vijay
>

---

From: <[email-masked]>
Date: Thu, 1 Mar 2007 09:47:09 -0600

Hi Robert,
Sounds like a good plan. Does that mean we are holding off on the DC
draft update?

I will have to skip the meeting for this time. But I will be available
electronically or telephonically when needed.

Regards,
Srini 

-----Original Message-----
From: ext Hancock, Robert [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 3:58 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] FW: [Mipshop] Soliciting agenda items for
MIPSHOPWG meeting at IETF68

folks,

r.

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]]
Sent: 01 March 2007 02:12
To: [email-masked]
Subject: [Mipshop] Soliciting agenda items for MIPSHOP WG meeting at
IETF68

Hello folks,

Vijay

---

From: <[email-masked]>
Date: Thu, 1 Mar 2007 13:56:03 -0600

I will not be at the meeting.

John 

>Sent: 01 March, 2007 01:58
>items for MIPSHOPWG meeting at IETF68
>
>folks,
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 2 Mar 2007 14:08:03 -0500

Hi,

I'll be there since Monday, so it would be nice if we could meet
sometime early in the week.

How about during Monday's "1520-1720 Afternoon Session II"?

Jc

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: March 1, 2007 10:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] FW: [Mipshop] Soliciting agenda items
forMIPSHOPWG meeting at IETF68

Hi Robert,

Regards,
Srini 

-----Original Message-----
From: ext Hancock, Robert [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 3:58 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] FW: [Mipshop] Soliciting agenda items for

folks,

r.

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]]
Sent: 01 March 2007 02:12
To: [email-masked]
Subject: [Mipshop] Soliciting agenda items for MIPSHOP WG meeting at
IETF68

Hello folks,

Vijay

---

From: Subir Das <[email-masked]>
Date: Fri, 02 Mar 2007 21:12:57 -0500

Robert,
Yes, I am arriving on Sunday noon time. At this time, 
I am flexible and available on: Mon- afternoon, Tue- evening
and Wed - early afternoon.

Thanks,
-Subir

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 07 Mar 2007 09:32:26 -0800

Hancock, Robert wrote:
> the DT. 

We have set aside 30 minutes for the design team update.

Vijay

that should give us time to do some work during the week, as

---

From: <[email-masked]>
Date: Wed, 7 Mar 2007 11:35:40 -0600

I will have Michael Williams or Gabor Bajko to represent for me, for any
offline discussions before the meeting.

Regards,
Srini 

-----Original Message-----
From: ext Vijay Devarapalli [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 11:32 AM
To: Hancock, Robert
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] FW: [Mipshop] Soliciting agenda items for

Vijay

---

From: "Robert Hancock" <[email-masked]>
Date: Sun, 18 Mar 2007 10:50:23 +0100

hi folks,

for people coming to the reception tonight, it would be good if we could
get together and plan our time for the rest of the week. we could also
have a drink or two and introduce ourselves to each other.

if one or both of the chairs can come, that would be lovely. i will
also ask Mike Williams if he can make it.

IIRC Juan Carlos arrives only Monday, but suggested Monday afternoon
second session for a proper working session. That would also be fine
for me. Unless we come across a good reason not to, I suggest we
meet at the session start at the registration desk and then try to find
somewhere to talk properly. (And if no-one else can make it, I'm sure
me and JC will have plenty to talk about ...)

cheers,

robert h.

> Sent: 01 March 2007 10:58

---

From: "Telemaco Melia" <[email-masked]>
Date: Sun, 18 Mar 2007 12:56:39 +0100

Hi guys,

I probably cannot make it for the welcome reception.
Count me in for Monday afternoon.

See you later.

Tele

-----Messaggio originale-----
Da: Robert Hancock [mailto:[email-masked]]
Inviato: dom 3/18/2007 10:50
A: 'Hancock, Robert'; [email-masked]
Oggetto: [MIPSHOP-MIH-DT] meeting in prague
 
hi folks,

cheers,

robert h.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Sun, 18 Mar 2007 18:20:37 -0400

Hi all,

Evidently, I didn't make it to the reception either. Sorry about missing
the drinks ;)
I'll see you tomorrow then.

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: Sunday, March 18, 2007 7:57 AM
To: Robert Hancock; [email-masked]
Subject: R: [MIPSHOP-MIH-DT] meeting in prague

Hi guys,

See you later.

Tele

-----Messaggio originale-----
Da: Robert Hancock [mailto:[email-masked]]
Inviato: dom 3/18/2007 10:50
A: 'Hancock, Robert'; [email-masked]
Oggetto: [MIPSHOP-MIH-DT] meeting in prague
 
hi folks,

cheers,

robert h.

---

From: sam xia <[email-masked]>
Date: Mon, 19 Mar 2007 17:35:39 +0800

hi, all,
 I have an internal meeting with my colleagues. sorry that I missed the meeting. see you this afternoon.

-----????-----
???: Zuniga, Juan Carlos [mailto:[email-masked]]
????: 2007?3?19? 6:21
???: Telemaco Melia; Robert Hancock; [email-masked]
??: RE: [MIPSHOP-MIH-DT] meeting in prague

Hi all,

Cheers,

Jc

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: Sunday, March 18, 2007 7:57 AM
To: Robert Hancock; [email-masked]
Subject: R: [MIPSHOP-MIH-DT] meeting in prague

Hi guys,

See you later.

Tele

-----Messaggio originale-----
Da: Robert Hancock [mailto:[email-masked]]
Inviato: dom 3/18/2007 10:50
A: 'Hancock, Robert'; [email-masked]
Oggetto: [MIPSHOP-MIH-DT] meeting in prague
 
hi folks,

cheers,

robert h.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 19 Mar 2007 14:41:43 -0400

Hello all,

I'm glad that we had such a good start this afternoon.
These are the 6 comments that I have for improving the PS. 
Please let me know if you have any thoughts about them.

Cheers,

Jc

--------------------------------------------------------

###################
##  Comment: 1   ##
###################

Section 4
Page 5
Current text: 

   "The deployment scenarios are outlined in the following sections.
   Note: while MN-to-MN signalling exchanges are theoretically possible,
   these are not currently being considered, and are out-of-scope."

Problem with the text:

The Problem Statement should not restrict such scenario. Allowing MN to
MN 
communications seems intuitively like a "nice-to-have" future proof
feature 
for the MIH Transport Mechanism. 

Solution:

Remove the text after the last comma: "and are out-of-scope"
 
--------------------------------------------------------

###################
##  Comment: 2   ##
###################

Section 5.2
Pages 12-13
Last paragraph (wrt p. 12)

Current text: 

            "Option 1 has a number of disadvantages associated with it,
            namely that ultimately the protocol design ends up
re-inventing
            a lot of the functionality already available in lower layers
at
            a higher layer where access to information about what is
going
            on in the network is restricted.  For example, how will the
            higher layer determine the cause of the error, if a message
is
            lost due to network congestion, it is pointless sending the
            message again.  It also adds to the complexity of the higher
            layer protocol, and makes successful deployment less certain
            (the protocol will have to be trialed in a number of network
            situations instead of re-using a protocol that has already
been
            tested)."

Problem with the text:

It's alright to discuss the two alternatives as seen immediately
preceding 
this paragraph. However, by mentioning at length the perceived issues
with 
ONLY ONE of the solutions, the Problem Statement seems to be going out
of 
its role. It is not necessary to hint at a solution in the Problem
Statement, 
especially in the light of the following facts:
            
1. Reliable transport mechanism might mean higher overhead, slower
connection 
set-up, complication in defining an MIH session, or combination of any
of 
these and other issues.

2. IEEE 802.21 provides some sort of reliability through the ACK-req and

ACK-rsp procedures. Hence, mentioning "re-inventing" seems to directly
question 
the IEEE standard itself and quite unnecessary. Therefore, the
reliability 
requirement should be an option, for instance dependant on the kind of
message 
being exchanged.

Solution:

Remove this paragraph. 

--------------------------------------------------------

###################
##  Comment: 3   ##
###################

Section 5.2
Page 11
2nd Paragraph in section 5.2

Current text:
            
"Discovery  MNs need the ability to locate nodes that support
particular mobility services in the network."

Problem with the text:

The text explicitly implies discovery of services. In other words, 
a node is discovered based on the services needed. IEEE 802.21 
describes the discovery of nodes first, and then it discovers 
services provided by the node (i.e. capabilities). 

Although the discovering of services is an interesting and perhaps 
efficient idea, we should not rule out the simple discovering of 
nodes only (i.e. with no knowledge of the service provided) in the PS.

Solution:

Leave the section general and allow for the two possibilities:
            
1. Discover node(s) first and then discover services for one or 
more of these nodes using relevant MIH messages (as specified in IEEE
802.21).

2. Depending on what services are needed, discover nodes that 
offer such service(s).

Hence, this would be a suggested alternative text:

"Discovery: MNs need the ability to either discover nodes that support 
certain services, or discover services provided by a certain node. The 
service discovery can be dealt with messages as defined in [1]. This
section 
refers to node-discovery in either scenario."

--------------------------------------------------------

###################
##  Comment: 4   ##
###################

Section 5
Page 9
Figure 5

Problem with the figure:

The figure seems to imply separate message headers for different kinds
of 
MIH message elements.  

Solution:

Replace Figure 5 with the following one:

 +------------------------------------------------------------+  ^
 |             Media Independent Handover Function            |  |
 |                                                            |  |
Mobility
 | ..................  ..................  .................. |  |
Service
 | :Mobility Support:  :Mobility Support:  :Mobility Support: |  | Layer
 | :    Service 1   :  :    Service 2   :  :    Service 3   : |  | 
 | :    (e.g. IS)   :  :    (e.g. ES)   :  :    (e.g. CS)   : |  |
 | ..................  ..................  .................. |  |
 |                                                            |  V
 +------------------------------------------------------------+
================================================================
 +------------------------------------------------------------+  ^
Mobility
 |             Mobility Service Transport Protocol            |  |
Service
 |                                                            |  |
Transport
 +------------------------------------------------------------+  V Layer
================================================================
 +------------------------------------------------------------+
 |                            IP                              |
 |                                                            |
 +------------------------------------------------------------+

--------------------------------------------------------

###################
##  Comment: 5   ##
###################

Section 4.3
Page 7
(after figure 3)

Current text:

   "The Proxy NN processes all layers of the protocol suite in the same
   way as an ordinary EP."
            
Problem with the text:

In light of today's discussion about the AP-in-the-middle case from
Michael, 
perhaps we should remove this paragraph.
Also, I'm still not sure if these should be called Proxies or Relays.

Solution:

Remove the paragraph and, "perhaps" change Proxy for Relay throughout
the document?

--------------------------------------------------------

###################
##  Comment: 6  ##
###################

Section 5.1
Page number 10
Paragraphs 2nd and 4th 

Current text:

            "The opaque payload encompasses the Mobility Support Service
            information that is to be transported.  The definition of
the
            Mobility Service Transport Header is something that is best
            addressed within the IETF.

            "2.  Payload Format: the format or the Mobility Support 
            Service Data payload could be represented in a number of 
            formats, e.g.  TLV, ASN/1, XML or text.  Ideally, a single
            payload representation should be defined, as support for
            multiple formats leads to unnecessary complexity.  It is 
            expected that a set of Data Objects will be defined for the 
            Mobility Support Services to exchange."

Problem with the text:

For the case of the 802.21 MIH, We are missing the Generic Frame header
here, 
and this again confuses MIH services with MIH Function and MIH protocol.

Solution:

Remove section 5.1 from the PS and perhaps move it to the DC document 
by fixing the "2. Payload Format..." paragraph by mentioning also the 
generic MIH Header.

---

From: Telemaco Melia <[email-masked]>
Date: Mon, 19 Mar 2007 19:52:33 +0100

Thanks Jc.
Subir could you please send your detailed comments asap?

thanks in advance
tele

Zuniga, Juan Carlos wrote:
> Michael,=20

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

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

---

From: Subir Das <[email-masked]>
Date: Tue, 20 Mar 2007 07:53:54 -0400

Telemaco,
Sorry for the delay. I have added my comments.
Search by my name. Btw, where are we meeting
today afternoon?

Thanks,
-Subir

Telemaco Melia wrote:
>> These are the 6 comments that I have for improving the PS. Please let 
>> me know if you have any thoughts about them.
>>
>> Cheers,
>>
>> Jc
>>
>> MN communications seems intuitively like a "nice-to-have" future proof
>> feature for the MIH Transport Mechanism.
>> Solution:
>>
>> preceding this paragraph. However, by mentioning at length the 
>> perceived issues
>> with ONLY ONE of the solutions, the Problem Statement seems to be 
>> going out
>> of its role. It is not necessary to hint at a solution in the Problem
>> Statement, especially in the light of the following facts:
>> connection set-up, complication in defining an MIH session, or 
>> combination of any
>> of these and other issues.
>>
>> question the IEEE standard itself and quite unnecessary. Therefore, the
>> reliability requirement should be an option, for instance dependant 
>> on the kind of
>> message being exchanged.
>>
>>
>> Solution:
>>
>> Remove this paragraph.
>> The text explicitly implies discovery of services. In other words, a 
>> node is discovered based on the services needed. IEEE 802.21 
>>             1. Discover node(s) first and then discover services for 
>> one or more of these nodes using relevant MIH messages (as specified 
>> in IEEE
>> 802.21).
>>
>> 2. Depending on what services are needed, discover nodes that offer 
>> such service(s).
>>
>> "Discovery: MNs need the ability to either discover nodes that 
>> support certain services, or discover services provided by a certain 
>> node. The service discovery can be dealt with messages as defined in 
>> [1]. This
>> section refers to node-discovery in either scenario."
>>
>> of MIH message elements. 
>>  | :    Service 1   :  :    Service 2   :  :    Service 3   : |  |  | 
>> :    (e.g. IS)   :  :    (e.g. ES)   :  :    (e.g. CS)   : |  |
>>             expected that a set of Data Objects will be defined for 
>> the             Mobility Support Services to exchange."
>>
>> Problem with the text:
>>
>> here, and this again confuses MIH services with MIH Function and MIH 
>> protocol.
>>
>>
>>
>> Solution:
>>

MIPSHOP                                                         T. Melia
Internet-Draft                                                       NEC
Intended status: Informational                               E. Hepworth
Expires: July 11, 2007                       Siemens Roke Manor Research
                                                         S. Sreemanthula
                                                   Nokia Research Center
                                                                 Y. Ohba
                                                                 Toshiba
                                                                G. Vivek
                                                                   Intel
                                                             J. Korhonen
                                                             TeliaSonera
                                                               R. Aguiar
                                                                      IT
                                                       Sam(Zhongqi). Xia
                                                                  HUAWEI
                                                         January 7, 2007

            Mobility Independent Services: Problem Statement
                      draft-ietf-mipshop-mis-ps-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 July 11, 2007.

Copyright Notice

Melia, et al.             Expires July 11, 2007                 [Page 1]

Internet-Draft              Mobility Services               January 2007

   Copyright (C) The Internet Society (2007).

Abstract

   There are on-going activities in the networking community to develop
   solutions that aid in IP handover mechanisms between heterogeneous
   wired and wireless access systems including, but not limited to, IEEE
   802.21.  Intelligent access selection, taking into account link layer
   attributes, requires the delivery of a variety of different
   information types to the terminal from different sources within the
   network and vice-versa.  The protocol requirements for this
   signalling have both transport and security issues that must be
   considered.  The signalling must not be constrained to specific link
   types, so there is at least a common component to the signalling
   problem which is within the scope of the IETF.  This draft presents a
   problem statement for this core problem.

Melia, et al.             Expires July 11, 2007                 [Page 2]

Internet-Draft              Mobility Services               January 2007

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Mobility Independent Services  . . . . . . . . .  5
   4.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  End-to-End Signalling and Transport over IP  . . . . . . .  6
     4.2.  End-to-End Signalling and Partial Transport over IP  . . .  6
     4.3.  End-to-End Signalling with a Proxy . . . . . . . . . . . .  7
     4.4.  End-to-End Network-to-Network Signalling . . . . . . . . .  8
   5.  Solution Components  . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Payload Formats and Extensibility Considerations . . . . .  9
     5.2.  Requirements on the Mobility Service Transport Layer . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

Melia, et al.             Expires July 11, 2007                 [Page 3]

Internet-Draft              Mobility Services               January 2007

1.  Introduction

   This Internet Draft provides a problem statement for the exchange of
   information to support handover in heterogeneous link environments.
   This mobility support service allows more sophisticated handover
   operations by making available information about network
   characteristics, neighboring networks and associated characteristics,
   indications that a handover should take place, and suggestions for
   suitable target networks to which to handover.  The mobility support
   services work complementarily with IP mobility mechanisms to enhance
   the overall performance and usability perception.

   There are two key attributes to the handover support service problem
   for inter-technology handovers:

   1.  The Information: the information elements being exchanged.  The
       messages could be of different nature, such as Information,
       Command or Event, potentially being defined following a common
       structure as defined.

Subir> The title of the bullet point and the text has some differences. 

   2.  The Underlying Transport: the transport mechanism to support
       exchange of the information elements mentioned above. 

  Subir> It is more than just transporting the IEs. Fr example, remote events and commands also need to be transported. 
       
       This transport mechanism includes information transport, discovery of
       peers, and the securing of this information over the network.

  Subir> We should separate the discovery from transport part. If we agree then we need to change the above sentence. 

   This draft has been motivated by on-going work within IEEE 802.21
   [1], but the following description intentionally describes the
   problem from a more general perspective.  This document represents
   the views of the authors, and does not represent the official view of
   IEEE 802.21. 

  Subir> Do we need to mention the sentence like the last one above. 

   The structure of this document is as follows.  Section 3 defines
   mobility services.  Section 4 provides a simple model for the
   protocol entities involved in the signalling and their possible
   relationships.  Section 5 describes a decomposition of the signalling
   problem into service specific parts and a generic transport part.
   Section 5.2 describes more detailed requirements for the transport
   component.  Section 6 provides security considerations, and Section 7
   summarizes the conclusions and open issues.

2.  Terminology

   The following abbreviations are used in the document:

   o  MIH: media independent handover

Melia, et al.             Expires July 11, 2007                 [Page 4]

Internet-Draft              Mobility Services               January 2007

   o  MN: mobile node

   o  NN: network node, intended to represent some device in the network
      (the location of the node e.g. in the access network, home network
      is not specified, and for the moment it is assumed that they can
      reside anywhere).

   o  EP: endpoint, intended to represent the terminating endpoints of
      the transport protocol used to support the signalling exchanges
      between nodes.

   o  MME: A Mobility Management Entity implements network selection and
      handover decision algorithms and utilizes mobility signaling
      protocols and other protocols that aid in mobility functions.
      Generalizing, we call this functional entity Policy Decision Point
      which acts upon events and combines required actions with user
      profiles.  The MME is able to collect information either from
      other network nodes or from the MN.

3.  Definition of Mobility Independent Services

   As mentioned in the introduction mobility (handover) support in
   heterogeneous wireless environments requires functional components
   located either in the mobile terminal or in the (access) network to
   exchange information and eventually to take decisions upon this
   information exchange.  For instance traditional host-based handover
   solutions could be complemented with more sophisticated network-
   centric solutions reducing terminal complexity.  Also, neighborhood
   discovery, potentially a complex operation in heterogeneous wireless
   scenarios, can result in a more simple step if implemented with an
   unified interface towards the access network.

   In this document the different supporting functions for media
   independent handover (MIH) management are generally referred as
   Mobility Independent Services (MIS) having in common different
   requirements for the transport protocol. 

Subir> Above sentence is not very clear. May consider revising it. 
       Also a diagram about these services would be helpful as described in section 5.

   These requirements and
   associated functionalities are the focus of this document

4.  Deployment Scenarios

   The deployment scenarios are outlined in the following sections.
   Note: while MN-to-MN signalling exchanges are theoretically possible,
   these are not currently being considered, and are out-of-scope.

   The following scenarios are discussed for understanding the overall
   problem of transporting MIH protocol.  Although these are all

Melia, et al.             Expires July 11, 2007                 [Page 5]

Internet-Draft              Mobility Services               January 2007

   possible scenarios and MIH services can be delivered through link-
   layer specific solutions and/or through a "layer 3 or above"
   protocol, this problem statement focuses on the delivery of
   information for MIH services for the latter case only.

4.1. End-to-End Signalling and Transport over IP 

Subir> Is it really end-to-end signaling or just simply end-to-end transport over IP

   In this case, the end-to-end signalling used to exchange the handover
   information elements (the Information Exchange) runs end-to-end
   between MN and NN.  The underlying transport is also end-to-end

           +------+                              +------+
           |  MN  |                              |  NN  |
           | (EP) |                              | (EP) |
           +------+                              +------+
                        Information Exchange
               <------------------------------------>

               /------------------------------------\
              <          Transport over IP           >
               \------------------------------------/

               Figure 1: End-to-end Signalling and Transport

4.2. End-to-End Signalling and Partial Transport over IP

Subir> Same as earlier. End-to-end signaling gives an impression that we are also providing additional signaling mechanism. 

   As before, the Information Exchange runs end-to-end between the MN
   and the second NN.  However, in this scenario, some other transport
   means than IP is used from the MN to the first NN, and the transport
   over IP is used only between NNs.  This is analogous to the use of
   EAP end-to-end between Supplicant and Authentication Server, with an
   upper-layer multihop protocol such as RADIUS used as a backhaul
   transport protocol between an Access Point and the Authentication
   Server. 

Subir> Instead of giving EAP as example here, we should just mention IP over the the backhaul (say ?point of attachment? to the backend network)and that should be sufficient to cover the .11u use case. Also the above sentence ?some other transport means than IP is used from the MN to the first NN, and the transport
   over IP is used only between NNs?  seems to me is not correct. Even for EAP the first hop is not IP, it is link specific EAP transport although the figure says ?transport over L2?.  

Melia, et al.             Expires July 11, 2007                 [Page 6]

Internet-Draft              Mobility Services               January 2007

           +------+           +------+           +------+
           |  MN  |           |  NN  |           |  NN  |
           |      |           | (EP) |           | (EP) |
           +------+           +------+           +------+
                        Information Exchange
               <------------------------------------>

                (Transport over  /------------------\
               <--------------->< Transport over IP  >
                    e.g. L2)     \------------------/

                        Figure 2: Partial Transport

4.3.  End-to-End Signalling with a Proxy

   In the final case, a number of proxies are inserted along the path
   between the two transport endpoints.  The use of proxies is possible
   in both cases 1 and 2 above, but distinguished here as there are a
   number of options as to how the proxy may behave with regard to the
   transport and end-to-end signalling exchange. 

  Subir> Do we care how the proxy behave w.r.t the mobility signaling protocol. 

   In this case, the proxy performs some processing on the Information
   Exchange before forwarding the information on.  This can be viewed as
   concatenating signalling exchanges between a number of EPs.

  Subir> What are the signaling exchanges above? Is it different than transport related signaling, e.g., transport connection establishment. 

           +------+         +---------+          +------+
           |  MN  |         | ProxyNN |          |  NN  |
           | (EP) |         |   (EP)  |          | (EP) |
           +------+         +---------+          +------+
                       Information Exchange
              ------------------>
                                ------------------->
                                <-------------------
              <------------------
              /---------------\     /----------------\
             <    Transport    >   <    Transport     >
              \---------------/     \----------------/

                  Figure 3: Information Exchange Approach

   The Proxy NN processes all layers of the protocol suite in the same
   way as an ordinary EP.

   There is a possibility for realizing other proxy scenarios.

Melia, et al.             Expires July 11, 2007                 [Page 7]

Internet-Draft              Mobility Services               January 2007

4.4.  End-to-End Network-to-Network Signalling

   In this case NN to NN signalling is envisioned.  Such model should
   allow different network components to gather information from each
   other.

  Subir> What do we mean by the above sentence?  

  This is useful for instance in conditions where network
   components need to take decisions and instruct mobile terminals of
   operation to be executed.

                 +------+          +------+
                 |  NN  |          |  NN  |
                 | (EP) |          | (EP) |
                 +------+          +------+
                    Information Exchange
                    ------------------->
                    <-------------------

                    /----------------\
                   <    Transport     >
                    \----------------/

            Figure 4: Information Exchange between different NN

   Network nodes exchange information about connected terminals status.

5.  Solution Components

   Figure 5 shows a model where the Information Exchanges are
   implemented by a signalling protocol specific to a particular
   mobility service, and these are relayed over a generic transport
   layer (the Mobility Service Transport Layer).

Melia, et al.             Expires July 11, 2007                 [Page 8]

Internet-Draft              Mobility Services               January 2007

                          +----------------+          ^
                          |Mobility Support|          |
                          |   Service 2    |          |
       +----------------+ |                |          | Mobility Service
       |Mobility Support| +----------------+          |    Signaling
       |    Service 1   |    +----------------+       |      Layer
       |                |    |Mobility Support|       |
       +----------------+    |   Service 3    |       |
                             |                |       |
                             +----------------+       V
     ================================================
        +---------------------------------------+     ^ Mobility Service
        |  Mobility Service Transport Protocol  |     |    Transport
        +---------------------------------------+     V      Layer
     ================================================
        +---------------------------------------+
        |                   IP                  |
        +---------------------------------------+

                    Figure 5: Handover Services over IP

   The Mobility Service Transport Layer provides certain functionality
   (outlined in Section 5.2) to the higher layer mobility support
   services in order to support the exchange of information between
   communicating mobility service functions.  The transport layer
   effectively provides a container capability to mobility support
   services, as well as any required transport and security operations
   required to provide communication without regard to the protocol
   semantics and data carried in the specific mobility services.

   The Mobility Support Services themselves may also define certain
   protocol exchanges to support the exchange of service specific
   Information Elements.  

   Subir> As mentioned above, it is not always information elements exchange. 
          Instead of ??. service specific Information Elements?, we should 
          Mention ??. Service specific features? or something like that. 

  It is likely that the responsibility for
   defining the contents and significance of the Information Elements is
   the responsibility of other standards bodies other than the IETF.
   Example mobility services include the Information Services, Event and
   Command services.

5.1.  Payload Formats and Extensibility Considerations

Melia, et al.             Expires July 11, 2007                 [Page 9]

Internet-Draft              Mobility Services               January 2007

   The format of the Mobility Service Transport Protocol is as follows:

   +----------------+----------------------------------------+
   |Mobility Service|           Opaque Payload               |
   |Transport Header|     (Mobility Support Service)         |
   +----------------+----------------------------------------+

                       Figure 6: Protocol Structure

   The opaque payload encompasses the Mobility Support Service
   information that is to be transported.  The definition of the
   Mobility Service Transport Header is something that is best addressed
   within the IETF. 

  Subir> The above paragraph is correct. The only question is: what is the 
         best terminology we should use. 

   There are a number of issues with regard to the Mobility Support
   Service header and payload definition.  These include:

   1.  Responsibility for defining the header: where should the contents
       of the Mobility Support Service header be defined, and should
       there be one or multiple header definitions (i.e. will a common
       header definition for all mobility support services be
       adequate?).  Where there are commonalities, it may indicate that
       these aspects should actually be included in the Mobility Service
       Transport Header.

   Subir> The above point is not entirely clear to me. For .21 use case, 
          MIH protocol has a common header format and services should be transparent to transport header. Unless we envision different transport requirements for different services, do we need the bullet #1? 

   2.  Payload Format: the format or the Mobility Support Service Data
       payload could be represented in a number of formats, e.g.  TLV,
       ASN/1, XML or text.  Ideally, a single payload representation
       should be defined, as support for multiple formats leads to
       unnecessary complexity.  It is expected that a set of Data
       Objects will be defined for the Mobility Support Services to
       exchange.

  Subir> Again how the above issue relates to transport design? If the payload is opaque, why this is an issue? If IETF does not define the payload this is a 
non-issue. 

   3.  Sharing of Data Objects: which refers to sharing the definitions
       of Data Objects between Mobility Support Services, e.g. if a
       Capabilities object is defined that is used by multiple Mobility
       Support Services, should the same definition be used by all of
       them.  If this is the case, then a common identifier space is
       needed to identify the different Data Objects.  There is a
       question about where the definition of Data Objects and the
       management of the identifier space should take place. 
   Subir> The above point is not clear to me. Which capability are we referring to here? Can someone explain to me the bullet #3? 

   The answers to some of the above issues may in part depend on how
   many standards groups are interested in defining their own Mobility
   Support Services.

Melia, et al.             Expires July 11, 2007                [Page 10]

Internet-Draft              Mobility Services               January 2007

5.2.  Requirements on the Mobility Service Transport Layer

   The following section outlines some of the general transport
   requirements that should be supported by the Mobility Service
   Transport Protocol.  Analysis has suggested that at least the
   following need to be taken into account:

   Discovery:  MNs need the ability to locate nodes that support
      particular mobility services in the network.  There are no
      assumptions about the location of these mobility services within
      the network, therefore the discovery mechanism needs to operate
      across administrative boundaries.  

     Subir> Also it should work across multiple subnets.
      
      Issues such as speed of
      discovery, protection against spoofing, when discovery needs to
      take place, and the length of time over which the discovery
      information may remain valid all need to be considered.
      Approaches include:

      *  Hard coding information into the MN, indicating either the IP
         address of the NN, or information about the NN that can be
         resolved onto an IP address.  The configuration information
         could be managed dynamically, but assumes that the NN is
         independent of the access network to which the MN is currently
         attached.

      *  Pushing information to the MN, where the information is
         delivered to the MN as part of other configuration operations,
         for example, in a Router Discovery exchange.  The benefit of
         this approach is that no additional exchanges with the network
         would be required, but the limitations associated with
         modifying these protocols may limit applicability of the
         solution.

      *  MN dynamically requesting information about a service, which
         may require both MN and NN support for a particular service
         discovery mechanism.  This may require additional support by
         the access network (e.g. multicast or anycast) even when it may
         not be supporting the service directly itself.

      Numerous directory and configuration services already exist, and
      reuse of these mechanisms may be appropriate.  There is an open
      question about whether multiple methods of discovery would be
      needed, and whether NNs would also need to discover other NNs.

      Subir> Since MN- MN is out scope, we should not mention about MN discovery  
             Here. 

      The definition of a service also needs to be determined, including
      the granularity of the description (for example, should the MN
      look for an "IS" service, or "IS-local information", and "IS-home
      network information" services.

Melia, et al.             Expires July 11, 2007                [Page 11]

Internet-Draft              Mobility Services               January 2007

   Information from a trusted source:  The MN uses the Mobility Service
      information to make decisions about what steps to take next.  It
      is essential that there is some way to ensure that the information
      received is from a trustworthy source.  This includes cases where
      trusted proxies along the path have access to, and may modify,
      parts of the Mobility Service information.  This requirement
      should reuse trust relationships that have already been
      established in the network, for example, on the relationships
      established by the AAA infrastructure after a mutual
      authentication, or on the certificate infrastructure required to
      support SEND [9].

   Low latency:  Some of the Mobility Services generate time sensitive
      information.  Therefore, there is a need to deliver the
      information over quite short timescales, and the required lifetime
      of a connection might be quite short lived.  For reliable
      delivery, short-lived connections could be set up as and when
      needed, although there is a connection setup latency associated
      with this approach.  Alternatively, a long-lived connection could
      be used, but this requires advanced warning of being needed and
      some way to maintain the state associated with the connection.  It
      also assumes that the relationships between devices supporting the
      mobility service are fairly stable.  Another alternative is
      connectionless operation, but this has interactions with other
      requirements such as reliable delivery.

   Reliability:  Reliable delivery for some of the mobility services may
      be essential, but it is difficult to trade this off against the
      low latency requirement.  It is also quite difficult to design a
      robust, high performance mechanism that can operate in
      heterogeneous environments, especially one where the link
      characteristics can vary quite dramatically.  There are two main
      approaches that could be adopted:

      1.  Assume the transport cannot be guaranteed to support reliable
          delivery.  In this case, the Mobility Support Service itself
          will have to provide some sort of reliability mechanism to
          allow communicating endpoints to acknowledge receipt of
          information.

      2.  Assume the underlying transport will deal with most error
          situations, and provide a very basic acknowledgement mechanism
          that (if no acknowledgement is received) will indicate that
          something more serious has occurred than a packet drop (since
          these other types of error conditions are dealt with at the
          transport layer).

      Option 1 has a number of disadvantages associated with it, namely

Melia, et al.             Expires July 11, 2007                [Page 12]

Internet-Draft              Mobility Services               January 2007

      that ultimately the protocol design ends up re-inventing a lot of
      the functionality already available in lower layers at a higher
      layer where access to information about what is going on in the
      network is restricted. For example, how will the higher layer
      determine the cause of the error, if a message is lost due to
      network congestion, it is pointless sending the message again.  It
      also adds to the complexity of the higher layer protocol, and
      makes successful deployment less certain (the protocol will have
      to be trialed in a number of network situations instead of re-
      using a protocol that has already been tested).

    Subir> We may not need the above paragraph since it is discussing other 
           Things than the problem statement. Also some of the sentences 
           are not clear. 

   Congestion Control:  A Mobility Service may wish to transfer large
      amounts of data, placing a requirement for congestion control in
      the transport.  There is an interaction between this requirement
      and that of the requirement for low latency since ways to deal
      with timely delivery of smaller asynchronous messages around the
      larger datagrams is required (mitigation of head of line blocking
      etc.).

   Secure delivery:  The Mobility Service information must be delivered
      securely between trusted peers, where the transport may pass
      though untrusted intermediate nodes and networks.  Design
      considerations may include whether session based or host based
      security associations are required along the chain of NNs, and
      what the rate limitation requirements of requests/responses might
      be.

   Multiplexing:  The transport service needs to be able to support
      different mobility services.  This may require multiplexing and
      the ability to manage multiple discovery operations and peering
      relationships in parallel.

   Multihoming:  For some information services exchanged with the MN,
      there is a possibility that the request and response messages can
      be carried over two different links e.g. a handover command
      request is on the current link while the response could be
      delivered on the new link.  Depending on the IP mobility
      mechanism, there is some impact on the transport option for the
      mobility information services.  This may potentially have some
      associated latency and security issues, for example, if the
      transport is over IP there is some transparency but Mobile IP may
      introduce additional delay and both TCP and UDP must use the
      permanent address of the MN.

  Subir> The last sentence of the above paragraph is not clear to me. 

   In addition to the above, it may be necessary for the transport to
   support multiple applications (or modes of operation) to support the
   particular requirements of the Information Exchange being carried out
   between nodes.  This may require the ability to multiplex multiple

Melia, et al.             Expires July 11, 2007                [Page 13]

Internet-Draft              Mobility Services               January 2007

   information exchanges into a single transport exchange (see figure
   Figure 7) .

  Subir> How the above is different than multiplexing? 

+==================================+
|                                  |
| +------------+  +-----------+    |
| |    MIH     |  |   MIH     |    |
| |   User 1   |  |  User 2   |... |
| |  e.g. MIP  |  |  e.g. SIP |    |
| ++++++++++++++  +++++++++++++    |  _    ..............
|      \                /          |   \__ :    MIH     :
|       \              /           |  _/   :Multiplexing:
|     +++++++++++++++++++++        |       :............:
|     |   MIH Function    |        |
|     |    (e.g. MIS)     |        |
|     +++++++++++++++++++++        |
|               /\                 |
|               ||                 |          ..............
|               ||                 |          : Transport  :
|               \/                 |          :Multiplexing:
|     +++++++++++++++++++++        |          :............:    +---------+
|     |     Transport     |        |               ____/\____   |   MIH   |
|     | (e.g. TCP, UDP)   |        |              /          \  |.........|
|     +++++++++++++++++++++        |                            |Transport|
|               /\                 |                            |.........|
|               ||                 |                       _____|   IP    |
|               ||                 |                      /     +=========+
|               ||                 |                     /
|               \/                 |    ^+++++++++^     /       +---------+
|     +++++++++++++++++++++        |   /           \   /        |   MIH   |
|     |         IP        |--------|--<  Internet   > -----     |.........|
|     +++++++++++++++++++++        |   \           /   |   \    |Transport|
|                                  |    v+++++++++v    |    \   |.........|
|                                  |                   |     \__|   IP    |
+==================================+                   |        +=========+
                                                       |             :
                                                       |             :
                                                       |        +---------+
                                                       |        |   MIH   |
                                                       |        |.........|
                                                       |        |Transport|
                                                       |        |.........|
                                                       |________|   IP    |
                                                                +=========+

                      Figure 7: Multiplexing examples

Subir> Do we need Figure 7 here? It would be better to have a similar figure at the beginning. 

Melia, et al.             Expires July 11, 2007                [Page 14]

Internet-Draft              Mobility Services               January 2007

6.  Security Considerations

   Network supported mobility services aim at improving decision making
   and management of dynamically connected hosts.  The control and
   maintenance of mobile nodes becomes challenging where authentication
   and authorization credentials used to access a network are
   unavailable for the purpose of bootstrapping a security association
   for handover services.

   Information Services may not require authorization of the client, but
   both event and command services must authenticate message sources,
   particularly if they are mobile.  Network side service entities will
   typically need to provide proof of authority to serve visiting
   devices.  Where signalling or radio operations can result from
   received messages, significant disruption may result from processing
   bogus or modified messages.  The effect of processing bogus messages
   depends largely upon the content of the message payload, which is
   handled by the handover services application.  Regardless of the
   variation in effect, message delivery mechanisms need to provide
   protection against tampering, and spoofing.

   Sensitive and identifying information about a mobile device may be
   exchanged during handover service message exchange.  Since handover
   decisions are to be made based upon message exchanges, it may be
   possible to trace an user's movement between cells, or predict future
   movements, by inspecting handover service messages.  In order to
   prevent such tracking, message confidentiality should be available.

   Subir> Tracking by whom? Mobility service provider will have the 
   ability to track even if message confidentiality is there. Are we referring 
   to intermediate nodes. If so, pl. make it clear. 
 
   This is particularly important since many mobile devices are
   associated with only one user, as divulgence of such information may
   violate the user's privacy.  Additionally, identifying information
   may be exchanged during security association construction.  As this
   information may be used to trace users across cell boundaries,
   identity protection should be available if possible, when
   establishing SAs.

   In addition, the user should not have to disclose its identity to the
   network (any more than it needed to during authentication) in order
   to access the Mobility Support Services.  For example, if the local
   network is just aware that an anonymous user with a subscription to
   operatorXYX.com is accessing the network, the user should not have to
   divulge their true identity in order to access the Mobility Support
   Services available locally.

   Subir> Can we anticipate such mobility service? Does the user need to attach the network? I am not sure whether the above should be a requirement? 

   Finally, the network nodes themselves will potentially be subject to
   denial of service attacks from MNs and these problems will be
   exacerbated if operation of the mobility service protocols imposes a
   heavy computational load on the NNs.  The overall design has to
   consider at what stage (e.g. discovery, transport layer

Melia, et al.             Expires July 11, 2007                [Page 15]

Internet-Draft              Mobility Services               January 2007

   establishment, service specific protocol exchange) denial of service
   prevention or mitigation should be built in.

7.  Conclusions

   This Internet draft outlined a broad problem statement for the
   signalling of information elements across a network to support media
   independent handover services.  In order to enable this type of
   signalling service, a need for a generic transport solution with
   certain transport and security properties were outlined.  Whilst the
   motivation for considering this problem has come from work within
   IEEE 802.21, a desirable goal is to ensure that solutions to this
   problem are applicable to a wider range of mobility services.

   It would be valuable to establish realistic performance goals for the
   solution to this common problem (i.e. transport and security aspects)
   using experience from previous IETF work in this area and knowledge
   about feasible deployment scenarios.  This information could then be
   used as an input to other standards bodies in assisting them to
   design mobility services with feasible performance requirements.

   Much of the functionality required for this problem is available from
   existing IETF protocols or combination thereof.  This document takes
   no position on whether an existing protocol can be adapted for the
   solution or whether new protocol development is required.  In either
   case, we believe that the appropriate skills for development of
   protocols in this area lie in the IETF.

8.  References

   [1]  "Draft IEEE Standard for Local and Metropolitan Area Networks:
        Media Independent Handover Services", IEEE LAN/MAN Draft  IEEE
        P802.21/D03.00, November 2006.

   [2]  Adoba, B., "Architectural Implications of Link Indications
        draft-iab-link-indications-03.txt", June 2005.

   [3]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
        August 2002.

   [4]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.

   [5]  Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
        Architecture", RFC 4423, May 2006.

Melia, et al.             Expires July 11, 2007                [Page 16]

Internet-Draft              Mobility Services               January 2007

   [6]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
        RFC 4555, June 2006.

   [7]  3GPP, "3GPP system architecture evolution (SAE): Report on
        technical options and conclusions", 3GPP TR 23.882 0.10.1,
        February 2006.

   [8]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
        July 2005.

   [9]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
        Neighbor Discovery (SEND)", RFC 3971, March 2005.

Authors' Addresses

   Telemaco Melia
   NEC Europe Network Laboratories
   Kufuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 90511 42
   Email: [email-masked]

   Eleanor Hepworth
   Siemens Roke Manor Research
   Roke Manor
   Romsey,   SO51 5RE
   UK

   Email: [email-masked]

   Srivinas Sreemanthula
   Nokia Research Center
   6000 Connection Dr.
   Irving,   TX 75028
   USA

   Email: [email-masked]

Melia, et al.             Expires July 11, 2007                [Page 17]

Internet-Draft              Mobility Services               January 2007

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscateway  NJ 08854
   USA

   Email: [email-masked]

   Vivek Gupta
   Intel Corporation
   2111 NE 25th Avenue
   Hillsboro, OR  97124
   USA

   Phone: +1 503 712 1754
   Email: [email-masked]

   Jouni Korhonen
   TeliaSonera Corporation.
   P.O.Box 970
   FIN-00051 Sonera
   FINLAND

   Phone: +358 40 534 4455
   Email: [email-masked]

   Rui L.A. Aguiar
   Instituto de Telecomunicacoes Universidade de Aveiro
   Aveiro  3810
   Portugal

   Phone: +351 234 377900
   Email: [email-masked]

   Sam(Zhongqi) Xia
   Huawei Technologies Co.,Ltd
   HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base,Hai-Dian District Beijing
   100085
   P.R. China

   Phone: +86-10-82836136
   Email: [email-masked]

Melia, et al.             Expires July 11, 2007                [Page 18]

Internet-Draft              Mobility Services               January 2007

Full Copyright Statement

   Copyright (C) The Internet Society (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 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 July 11, 2007                [Page 19]

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 20 Mar 2007 13:31:59 +0100

hi,

just a reminder: the rest of this week, we meet
Tuesday Afternoon III/IV (17:40)
Wednesday Morning I (09:00)
Thursday Afternoon I (13:00)
and then Thursday evening to eat (assuming the design team still exists)

in all cases: meet at (or near) the IETF registration desk and then we try
to find somewhere quiet (and smoke free?) to sit.

robert h.

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 20 Mar 2007 13:37:16 +0100

hi,

just a ping to check whether that brief discussion about information
elements was in line with what everyone else was assuming. that is:

- the DT is only looking at the transport problem
- and the DT has no plans to look at the information element problem
- (and probably that there is no need for the charter item at all)

I think that in the past, there has been an occasional re-interpration of
the 'Information Elements' milestone as being something like a 'how to use
the mipshop solution to carry stuff', like a user's guide, as distinct from
the protoocol specification itself. Certainly the DT work should cover that.
But I don't see the need for a distinct milestone for it.

robert h.

---

From: sam xia <[email-masked]>
Date: Tue, 20 Mar 2007 20:44:26 +0800

-----Original Message-----
From: Robert Hancock [mailto:[email-masked]]
Sent: Tuesday, March 20, 2007 8:37 PM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] information elements

hi,

sam> i agree.

robert h.

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 20 Mar 2007 14:00:10 +0100

hi all,

just some follow ups: 

> From: Zuniga, Juan Carlos [mailto:[email-masked]] 
> Sent: 19 March 2007 19:42
> To: [email-masked]; Telemaco Melia
> Cc: [email-masked]
> Subject: [MIPSHOP-MIH-DT] comments on PS
> 
> Hello all,
> 
> The Problem Statement should not restrict such scenario. 
> Allowing MN to MN communications seems intuitively like a 
> "nice-to-have" future proof feature for the MIH Transport Mechanism. 
> 
> Solution:
> 

fine with me. but I think it would be a significant extension.
i wouldn't want to use extensibility to this case as a strong
evaluation criterion, just a nice-to-have.

>             namely that ultimately the protocol design ends 
> up re-inventing
>             a lot of the functionality already available in 
> lower layers at
>             a higher layer where access to information about 
> what is going
>             higher layer determine the cause of the error, if 
> a message is
>             situations instead of re-using a protocol that 
> has already been
>             tested)."
> 
> Problem with the text:
> 
> It's alright to discuss the two alternatives as seen 
> immediately preceding this paragraph. However, by mentioning 
> at length the perceived issues with ONLY ONE of the 
> solutions, the Problem Statement seems to be going out of its 
> role. It is not necessary to hint at a solution in the 
> Problem Statement, especially in the light of the following facts:
>             
> 1. Reliable transport mechanism might mean higher overhead, 
> slower connection set-up, complication in defining an MIH 
> session, or combination of any of these and other issues.
> 
> ACK-rsp procedures. Hence, mentioning "re-inventing" seems to 
> directly question the IEEE standard itself and quite 
> unnecessary. Therefore, the reliability requirement should be 
> an option, for instance dependant on the kind of message 
> being exchanged.
> 
> 
> Solution:
> 
> Remove this paragraph. 

OK with me. I still believe the text is entirely correct but
we can have the discussion in the DT instead. It is always good
to keep the PS short.

> The text explicitly implies discovery of services. In other 
> words, a node is discovered based on the services needed. 
> IEEE 802.21 describes the discovery of nodes first, and then 
> it discovers services provided by the node (i.e. capabilities). 
> 
> Although the discovering of services is an interesting and 
> perhaps efficient idea, we should not rule out the simple 
> discovering of nodes only (i.e. with no knowledge of the 
> service provided) in the PS.
> 
> 
> 
> Solution:
> 
> 1. Discover node(s) first and then discover services for one 
> or more of these nodes using relevant MIH messages (as 
> specified in IEEE 802.21).
> 
> "Discovery: MNs need the ability to either discover nodes 
> that support certain services, or discover services provided 
> by a certain node. The service discovery can be dealt with 
> messages as defined in [1]. This section refers to 
> node-discovery in either scenario."

I think there is a potential terminology issue here. 'Discovery'
can mean all sorts of different things to different people. Two 
aspects:

- rather than 'discover services supported by a certain node'
(like .21 system management), maybe we should use a term like
capability negotiation. (i.e. to avoid two different uses of the
word 'discovery').

- certainly we can leave the general question general. Maybe a 
way to do that would be to say that we do not pre-judge the
internal structure of a mobility service and what type of 
capability negotiation it carries out.

[In other words, that we don't say whether ES/CS/IS are three
different services or one, from our perspective.]

> The figure seems to imply separate message headers for 
> different kinds of MIH message elements.  
> 
> 
> Solution:
> 
>   V Layer
personally I prefer the existing version (see above discussion).

This is certainly correct. Maybe we need to say more generally that
"the MSTP does not care about the type of processing that is carried
out above it, e.g. whether it is full protocol processing, or some
kind of proxy or relay function".
(There are no universally accepted definitions for proxy/relay, and
I think we should just leave the text vague, especially since the
functionality is in any case out of our scope.)

I would like to keep 5.1. We could lose the stuff on payload formats,
but the stuff about the MSTP header is important: an MSTP user (like
802.21, or 802.21 IS, or MIHP, or MIHF, or whatever you call it...)
will need to be associated with a demultiplexing value in the MSTP
header, so this is a clear point about the boundary of different
problem spaces (and so appropriate for the PS).

r.

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 20 Mar 2007 15:07:32 +0100

Guys,

I am trying to put comments together.
I ll distribute a txt file hopefully in 1 hour or so...

See you later

telemaco

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 20 Mar 2007 10:51:22 -0400

Hi,

That is also my understanding.

Cheers,

Jc

-----Original Message-----
From: sam xia [mailto:[email-masked]] 
Sent: March 20, 2007 8:44 AM
To: Robert Hancock; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] information elements

-----Original Message-----
From: Robert Hancock [mailto:[email-masked]]
Sent: Tuesday, March 20, 2007 8:37 PM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] information elements

hi,

sam> i agree.

I think that in the past, there has been an occasional re-interpration
of
the 'Information Elements' milestone as being something like a 'how to
use
the mipshop solution to carry stuff', like a user's guide, as distinct
from
the protoocol specification itself. Certainly the DT work should cover
that.
But I don't see the need for a distinct milestone for it.

robert h.

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 20 Mar 2007 16:15:12 +0100

Hi guys,

I just compiled a first summary.
If Robert agrees I would like to go through it trying to "finalize" 
changes to be applied to the PS document.
Once this is done we can send them to the mailing list, hopefully 
getting consensus for WGLC.

Let me know what do you think.

tele
 
Telemaco Melia wrote:
> ------------------------------------------------------------------------
>

Issues to be addressed

Introduction
============

- comment on Information elements (IEs): this is a general term, do we need to clarify the term?
- comment on seprating discovery and transport: do we agree on this?
- comment "Do we need to mention the sentence like the last one above." ==> better explain

Terminology Section
===================
- Remove MME

Definition of Mobility Independent Services
===========================================

- comment (Subir) Above sentence is not very clear. May consider revising it. 
       Also a diagram about these services would be helpful as described in section 5.

Deployment Scenarios
====================

- suggestion to change the title to "Deployment Scenarios for MIS"

- specific comment: 

Problem with the text:

Solution:

[COMMENT] I would leave it there, if possible.

- comment section 4.1
  Propose to change to "End-to-End Signalling Transport over IP" 
 
- comment section 4.2 EAP example
Should we adopt the general example discussed for .11u?

- specific comment: Section 4.3 Page 7 (after figure 3)

Current text:

Problem with the text:

In light of today's discussion about the AP-in-the-middle case from
Michael, perhaps we should remove this paragraph.
Also, I'm still not sure if these should be called Proxies or Relays.

Solution:

[COMMENT] Proposed text: "the MSTP does not care about the type of processing that is carried
out above it, e.g. whether it is full protocol processing, or some
kind of proxy or relay function"

- comment section 4.4
NN to NN communication: is not that clear?

Solution Components
===================

- The name of the section is probably misleading. 
Porposed alternative: "Transport layer interactions for MIS"

- Terminology to be updated:
"Mobility Service Transport Protocol", proposal "???"

- specific comment on figure 5:

Problem with the figure:

Solution:

[COMMENT] I tend to disagree with the proposal. So far in the mailing list we stated that the 
transport layer solution is NOT aware of the specific mobility support service datagrams. The transport
layer just needs to be configured prior to send packets.

[COMMENT] Robert prefers the current version

- Section 5.1  Page number 10 Paragraphs 2nd and 4th 

Current text:

Problem with the text:

For the case of the 802.21 MIH, We are missing the Generic Frame header
here, and this again confuses MIH services with MIH Function and MIH protocol.

Solution:

[COMMENT] I do not see why we would need to care about the generic frame header.
MIH defines the required header (fixed and not) and the payload. Do people think the picture
belongs already to the solution space document?
 
[COMMENT] in my opinion we should support different transport requirements for different services. So we need bullet #1.

[COMMENT] sharing data objects: should we consider this for the DT work?

[COMMENT] Robert prefers to keep current section 5.1.

- Section 5.2

- comment page 11 Since MN- MN is out scope, we should not mention about MN discovery  here.

- comment Page 11 2nd Paragraph 

Current text:

Problem with the text:

Solution:

[COMMENT] I agree that we have to refer to the discovery in 802.21.
Though the text is not yet clear. could you clarify?

[COMMENT] Clarify the term Discovery in this context

-comment Pages 12-13 Last paragraph (wrt p. 12)

Current text: 

            "Option 1 has a number of disadvantages associated with it,
            namely that ultimately the protocol design ends up re-inventing
            a lot of the functionality already available in lower layers at
            a higher layer where access to information about what is going
            on in the network is restricted.  For example, how will the
            higher layer determine the cause of the error, if a message is
            lost due to network congestion, it is pointless sending the
            message again.  It also adds to the complexity of the higher
            layer protocol, and makes successful deployment less certain
            (the protocol will have to be trialed in a number of network
            situations instead of re-using a protocol that has already been
            tested)."

Problem with the text:

It's alright to discuss the two alternatives as seen immediately preceding 
this paragraph. However, by mentioning at length the perceived issues with 
ONLY ONE of the solutions, the Problem Statement seems to be going out of 
its role. It is not necessary to hint at a solution in the Problem Statement, 
especially in the light of the following facts:
            
1. Reliable transport mechanism might mean higher overhead, slower connection 
set-up, complication in defining an MIH session, or combination of any of 
these and other issues.

2. IEEE 802.21 provides some sort of reliability through the ACK-req and
ACK-rsp procedures. Hence, mentioning "re-inventing" seems to directly question 
the IEEE standard itself and quite unnecessary. Therefore, the reliability 
requirement should be an option, for instance dependant on the kind of message 
being exchanged.

Solution:

Remove this paragraph. 

{same comment from Subir}
{also Robert seems to agree}

---

From: "Stefano Faccin" <[email-masked]>
Date: Tue, 20 Mar 2007 08:15:26 -0700

So you all agree on removing the MIH info element draft from the
charter? If we need to define anything about that, it can be in the spec
on the solution (and that does not eman the DT has to define that).
Stefano

-----Original Message-----
From: Zuniga, Juan Carlos [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2007 7:51 AM
To: sam xia; Robert Hancock; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] information elements

Hi,

Cheers,

Jc

-----Original Message-----
From: sam xia [mailto:[email-masked]] 
Sent: March 20, 2007 8:44 AM
To: Robert Hancock; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] information elements

-----Original Message-----
From: Robert Hancock [mailto:[email-masked]]
Sent: Tuesday, March 20, 2007 8:37 PM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] information elements

hi,

sam> i agree.

robert h.

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 20 Mar 2007 16:26:35 +0100

Fine with me.

telemaco

---

From: <[email-masked]>
Date: Tue, 20 Mar 2007 10:26:14 -0500

Hi All,
May be we should look at the solutions to determine how it/they can be
split or organised. I would consider that as a place holder, if a need
arises later. If nothing comes up, we just remove it.

Thanks,
Srini

-----Original Message-----
From: ext Stefano Faccin [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2007 10:15 AM
To: Zuniga, Juan Carlos; sam xia; Robert Hancock;
[email-masked]

-----Original Message-----
From: Zuniga, Juan Carlos [mailto:[email-masked]]
Sent: Tuesday, March 20, 2007 7:51 AM
To: sam xia; Robert Hancock; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] information elements

Hi,

Cheers,

Jc

-----Original Message-----
From: sam xia [mailto:[email-masked]]
Sent: March 20, 2007 8:44 AM
To: Robert Hancock; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] information elements

-----Original Message-----
From: Robert Hancock [mailto:[email-masked]]
Sent: Tuesday, March 20, 2007 8:37 PM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] information elements

hi,

sam> i agree.

robert h.

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 21 Mar 2007 12:08:06 +0100

hi all,

my slides and michael's notes (thanks michael!)

robert h.

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 21 Mar 2007 08:45:27 -0400

Hi guys,

I know that I'm supposed to write down the conclusions, but I think that
Michael's notes are very comprehensive of the discussions. However,
before closing this topic I still have one or two questions that I'd
like to clarify, so I inserted them into Michael's notes. Please feel
free to comment.

Cheers,

Jc

-----Original Message-----
From: Robert Hancock [mailto:[email-masked]] 
Sent: March 21, 2007 7:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: [MIPSHOP-MIH-DT] slides and notes from this morning

hi all,

robert h.