Subject: [Mipshop] Adopting draft-soliman-mipshop-4140bis-01.txt as a WG document

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Nov 2006 14:27:44 -0800

Hello,

this starts a two week consensus call to adopt
draft-soliman-mipshop-4140bis-01.txt as a WG
document in the MIPSHOP WG. you can find the
draft at
http://www.ietf.org/internet-drafts/draft-soliman-mipshop-4140bis-01.txt

we have an item in the charter to publish
Hierarchical Mobile IPv6 as a proposed standard.
this document addresses the charter item. please
send an email to the mailing list to indicate
if you support/not support this.

the consensus call will end on Nov 23 2006.

Vijay

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

---

From: "Faccin, Stefano M" <[email-masked]>
Date: Fri, 10 Nov 2006 10:24:50 -0800

Hello,

this starts a two week consensus call to adopt draft-melia-mipshop-mobility-services-ps-01.txt as a WG
document in the MIPSHOP WG. You can find the draft at: http://www.ietf.org/internet-drafts/draft-melia-mipshop-mobility-services-ps-01.txt

We have an item in the charter to publish solutions for the transport of Media Independent Services. This document addresses the problem statement for the charter item. Please send an email to the mailing list to indicate if you support/not support this. The consensus call will end on Nov 23 2006.

Stefano M. Faccin

Marvell
Cellular and Handheld Group

May the Force be with you
_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Faccin, Stefano M" <[email-masked]>
Date: Fri, 10 Nov 2006 10:31:59 -0800

Hello,

Stefano M. Faccin

Marvell

---

From: "Daniel Park" <[email-masked]>
Date: Thu, 16 Nov 2006 06:43:09 +0900

I support on the WG adoption even I made a couple of concerns on the document.

http://www1.ietf.org/mail-archive/web/mipshop/current/msg02970.html

Appreciate authors' efforts.

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

On 11/11/06, Faccin, Stefano M <[email-masked]> wrote:
> draft-melia-mipshop-mobility-services-ps-01.txt as a WG
> document in the MIPSHOP WG. You can find the draft at:
> http://www.ietf.org/internet-drafts/draft-melia-mipshop-mobility-services-ps-01.txt
>
> We have an item in the charter to publish solutions for the transport of
> Media Independent Services. This document addresses the problem statement
> for the charter item. Please send an email to the mailing list to indicate
> if you support/not support this. The consensus call will end on Nov 23 2006.
>
> Stefano M. Faccin
>
> Marvell

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 22 Nov 2006 17:11:11 -0500

Hello all,

I also support the WG adoption of the PS document. However, as I mentioned during its presentation in San Diego, I think that the problem statement can still be greatly simplified and clarified.

In an effort to achieve such clarification and simplification, I have the following detailed comments:

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

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

Section(s): 1 and 4
Page number(s): 4 and 5 (respectively)
Paragraph: 5th (wrt section 1) and 1st (wrt section 4)
Current text: 

            "This draft has been motivated by on-going work within IEEE
            802.21, 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."

            "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:

IEEE 802.21/D02.00 does not limit message exchanges to a client-server model only, but rather it allows the MIH to work in a peer-to-peer manner. The Problem Statement should not restrict such scenario. Moreover, allowing MN to MN communications seems intuitively like a "nice-to-have" future proof feature for the MIH Transport Mechanism. 

Solution:

Either remove the part of the Note on the second paragraph above (marked by arrows), or rephrase it as follows:
 "While MN-to-MN communication is apparently not a likely scenario, a general transport solution should be able to address such peer-to-peer communication as well."
 
--------------------------------------------------------

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

Section(s): 5.2
Page number(s): 12
Paragraph: 3rd (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 was alright to discuss the two alternatives as seen immediately preceding this paragraph. However, by mentioning at length the perceived issues with 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 or more 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 completely, since it provides no greater insight, hints at a particular solution and raises some questions about features already provided within IEEE 802.21. 

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

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

Section(s): 1
Page number(s): 4
Paragraph: 3, 4 and 5 (wrt section 1)
Current text:

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

    1. The Information and Information Exchange mechanism: this includes
       the information elements that describe the information, and any
       signalling exchanges that are required to support the transfer of
       these Information Elements.

   2.  The Underlying Transport: this supports the above Information
       Exchange between devices in the network.  The requirements on
       this transfer mechanism include transport issues, because of the
       volume of data to be sent, as well as discovery and security
       issues for this transport, as the signalling may cross
       administrative boundaries and is interdependent with AAA aspects."

Problem with the text:

This is relevant to Daniel's previous comment. 

On being read, the line seems to include a circular definition. It is very ambiguous as to what exactly is being said, which makes it difficult to offer a solution to this problem. Additionally, the distinction between "information exchange mechanism" and "underlying transport" is not clear.

Solution: 

First, clearly state that there are two entities: 1) message elements and 2) transport mechanism for these elements. Second, make the separation between the two clear. One possible text is as follows:

"The two main components of the inter-technology handover support service
are:

1. The Information: The information elements being exchanged (e.g. as defined in [1]). The messages could be of different nature, such as Information, Command or Event, but typically they have a common structure as defined in [1].

 2. The Underlying Transport: The transport mechanism to support exchange of the information elements mentioned above. This transport mechanism includes information transport, discovery of peers, and the securing of this information over the network."

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

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

Section(s): 5.2
Page number(s): 12 and 13
Paragraph: 6th (wrt p. 12) and 2nd (wrt p. 13)
Current text: 

            "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."

            "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 information exchanges into a single
            transport exchange."
            
Problem with the text:

The text seems to unnecessarily complicate matters involving multiplexing. Two levels of multiplexing could be contemplated:
 
            1. On a single node, multiple upper layer applications (e.g. Mobile IP, Mobility Policy, SIP, etc) may use the MIH services from the MIH Function (e.g. Information Services, Command Services, Event Services, etc.). However, this sort of multiplexing can be dealt with using the current Session ID's and Transaction ID's defined in the IEEE 802.21/D02.00 standard draft. So multiple "mobility services" (as expressed in the PS) does not impose any sort of extra requirement on the underlying transport mechanism.

            2. The MIH function on a single node may communicate with multiple peers at the same time. In order to handle this sort of multiplexing, the transport layer should support multiple sessions using whatever means is best suited, such as multiple Internet sockets.

Solution:

Remove the texts mentioned since they refer to the first case of multiplexing, which can be dealt with, using what is provided by 802.21. For the second case, mention:
"The transport layer should be able to support communication with multiple peer nodes at the same time."

In addition, the following image may be used to portray the nature of multiplexing:

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

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

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

Section(s): 5.2
Page number(s): 10-11
Paragraph: 2nd (wrt s. 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. IEEE802.21/D02.00 currently describes the mechanism differently, as it discover nodes and then it discovers services provided by the node(s). Hence the text contradicts the standard (draft). Although the discovering of services is an interesting and perhaps efficient idea, we should not rule out the discovering of nodes only (i.e. with no knowledge of the service provided) in the Problem Statement.

Solution:

Leave the section general and allow for both 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: 6   ##
###################

Problem with the text:

Although IEEE 802.21 is being referenced throughout the text, there is little information provided about the IEEE 802.21 concepts.

Solution:

Add a new section that briefly describes what MIH (i.e. 802.21) already provides so as to avoid re-inventing existing functionalities. For instance, there is no need to define special headers for the different services since the MIH Frame (as defined in IEEE 802.21) provides a generic frame format for all service types.

The following text can be used as "Overview of Media Independent Handover", for instance after the "Definition of Mobility Services" (Section 3).

-----------------------------------------
(New Section after Section 3)

X. Overview of Media Independent Handover

This section gives a brief overview of the Media Independent Handover (MIH) concept that the IEEE 802.21 is developing.

The IEEE 802.21 specification provides link layer intelligence and other related network information to upper layers to optimize handovers between heterogeneous media [1].

IEEE 802.21 defines an MIH Function (MIHF) that implements services which include Information Service (IS), Command Service (CS), and Event Service (ES). These services are used by an MIH Application to enhance seamless mobility across different access networks.

            +++++++++++++++++++++++++++++++++++++++++++++++++
            |              MIH Application                  |
            |  (e.g. Mobility Policy, SIP, Mobile IP, etc.) |
            |                                               |
            +++++++++++++++++++++++++++++++++++++++++++++++++
                  
          _ +++++++++++++++++++++++++++++++++++++++++++++++++          
Scope    /  |                                               |               of IEEE <   |            MIHF (e.g. IS, CS, ES, etc.)       |    
802.21   \_ |                                               |
            +++++++++++++++++++++++++++++++++++++++++++++++++          

          _ +++++++++++++++++++++++++++++++++++++++++++++++++          
Scope    /  |                                               |
Of IETF <   |         Transport (e.g. UDP, TCP, etc.)       |
MIPSHOP  \_ |                                               |
            +++++++++++++++++++++++++++++++++++++++++++++++++

            +++++++++++++++++++++++++++++++++++++++++++++++++
            |                                               |
            |         Network (e.g. IPv4, IPv6, etc.)       |
            |                                               |
            +++++++++++++++++++++++++++++++++++++++++++++++++

Peer MIHFs can exchange messages by using MIH Frames as defined in IEEE 802.21. These frames are made up of two main parts - MIH Fixed Header and MIH Variable Load. The MIH Variable Load is in turn made up of two sub-parts - the MIH Variable Header and the MIH Payload. The following figure shows the MIH Frame Format:

|<------------------- MIH Frame Format -------------------->|

+--------------------+--------------------------------------+
| MIH FIXED HEADER   |         MIH VARIABLE LOAD            |      
|                    |                 []                   |                     
|                    |  MIH Variable   []   MIH Payload     | 
|                    |     Header      []                   |
+--------------------+--------------------------------------+    

The Fixed Header contains the following fields:

     - Service Identifier: Identifies the type of MIH Service that a message (MIH Payload) is related to i.e. IS, CS, or ES.

     - Transaction ID: This is an identifier that is used with every MIH initiator and its response message. 
It is required to match each request, response or indication message and its acknowledgment.
            
     - ACK-Req: used to request acknowledgement of MIH messages. The use of this field is optional.

     - ACK-Rsp: used to acknowledge a previously received message.

The MIH Variable Header contains the following fields:

     - MIH Function ID: uniquely defines an MIHF endpoint.

     - MIH Session ID - identifies ongoing session(s) between MIHF endpoints. 

The MIH Payload:

     - It contains the data (i.e. IS, CS, or ES), and IEEE 802.21 specifies how these fields should be used when sending MIH messages.

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

###################
##  Comment: 7   ##
###################

Section: 4 - Deployment Scenarios
Page Number: 5
Paragraph: 2 (w.r.t Section 4)
Current text: 

            "The following scenarios are discussed for understanding the
            overall problem of transporting MIH protocol and is not intended
            to show the scenarios are part of the requirements in the 
            transport design."

Problem with the text: 

Even though all these scenarios are possible, the Problem Statement document only targets the "Transport over IP" portions of these scenarios, as mentioned in the MIPSHOP charter.

Solution: 

Replace the whole paragraph with the following text:

"The following scenarios are discussed for understanding the overall problem of transporting MIH protocol. Although these are all 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 this latter case only."

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

###################
##  Comment: 8   ##
###################

Section(s): 5
Page number(s): 8
Paragraph: Figure 5

Problem with the figure:

The figure seems to imply separate message headers for different kinds of MIH message elements. However, as can be seen from section 8.3.4 of IEEE802.21/D02.00, there is a unified fixed message header for all MIH messages (see Comment 6 above). 

The Service ID allows identification of the kind of message (e.g. System Management, Event Service, etc.) and therefore the figure is confusing. Also, since the Problem Statement concerns the transport mechanism, there is no reason to step into details of the messages themselves, especially when they have been defined rather well in the IEEE 802.21 standard (draft) itself.

Solution:

Replace Figure 5 with the following one:

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

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

###################
##  Comment: 9   ##
###################

Section(s): 4.3
Page number(s): 7
Paragraph: 1st (wrt s. 4.3)
Current text:

            "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."
            
Problem with the text:

Use of layer 3 proxies in the transport is not really within the scope of the Transport of MIH. However, in case that individual implementations decided to use such proxies in their communication chain, the chain could be broken up into pairs of EP-to-EP nodes, which the transport would see as independent peers (i.e. not chained), as shown in the example given in section 4.4 (i.e. EP-to-EP, NN-to-NN signalling).

Solution:

Remove section 4.3 (including Figure 3), as it adds no useful information to the problem statement.

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

###################
##  Comment: 10  ##
###################

Section(s): 5.1
Page number(s): 9
Paragraph: 2nd and 4th (wrt s. 5.1)
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:

The IEEE802.21/D02.00 standard (draft) already defines the MIH Frame format which contains a Fixed Header section (see Comment 6 above). This header is generic and can be used to represent all three MIHF services (i.e. IS, CS, ES). Thus there is no need to re-define new service specific headers for such a function.

IEEE 802.21 specifies that the choice of specific payload format is optional and thus this issue is taken care of by IEEE 802.21. There is no need to re-tackle this issue again. 

Solution:

Remove section 5.1, as both issues have already been taken into consideration in IEEE 802.21.

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

Best regards,

Juan Carlos Zuniga

-----Original Message-----
From: Daniel Park [mailto:[email-masked]] 
Sent: November 15, 2006 4:43 PM
To: Faccin, Stefano M
Cc: [email-masked]; Vijay Devarapalli
Subject: Re: [Mipshop] REISSUED: Adoptingdraft-melia-mipshop-mobility-services-ps-01.txt as a WG draft

--