Re: [MIPSHOP-MIH-DT] PS doc -- 01 version
Telemaco Melia <telemaco.melia@netlab.nec.de> Mon, 30 April 2007 16:07 UTC
Return-path: <mipshop-mih-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYPD-0007wP-5C; Mon, 30 Apr 2007 12:07:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiYPC-0007wE-3O for mipshop-mih-dt@ietf.org; Mon, 30 Apr 2007 12:07:14 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiYP7-0006CA-8s for mipshop-mih-dt@ietf.org; Mon, 30 Apr 2007 12:07:14 -0400
Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5B56D2000189; Mon, 30 Apr 2007 18:26:16 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sihmX9uxrCDs; Mon, 30 Apr 2007 18:26:16 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2C9BD200017C; Mon, 30 Apr 2007 18:26:06 +0200 (CEST)
Received: from [127.0.0.1] ([10.1.1.217]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Apr 2007 18:06:58 +0200
Message-ID: <46361421.8030301@netlab.nec.de>
Date: Mon, 30 Apr 2007 18:06:57 +0200
From: Telemaco Melia <telemaco.melia@netlab.nec.de>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: mipshop-mih-dt@ietf.org
Subject: Re: [MIPSHOP-MIH-DT] PS doc -- 01 version
References: <462F854D.2040609@netlab.nec.de> <4631A288.5010906@netlab.nec.de> <46360F7C.4030109@research.telcordia.com>
In-Reply-To: <46360F7C.4030109@research.telcordia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Apr 2007 16:06:58.0097 (UTC) FILETIME=[94534A10:01C78B41]
X-Spam-Score: 2.3 (++)
X-Scan-Signature: e8ea636ec013593313c7b28da6453598
Cc:
X-BeenThere: mipshop-mih-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MIPSHOP Media Independent Handover Design Team List <mipshop-mih-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/mipshop-mih-dt>
List-Post: <mailto:mipshop-mih-dt@ietf.org>
List-Help: <mailto:mipshop-mih-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=subscribe>
Errors-To: mipshop-mih-dt-bounces@ietf.org
Hi all, As far as I know only Robert is missing. Tomorrow in Germany is bank holiday. I ll be back in the office on Wednesday and I ll compile the final version. cheers Tele Subir Das wrote: > Tele, > Sorry for the delay. Hope it is not too late. > Inserted below with a few comments/suggestions. > Search by my name. > > thanks, > -Subir > > Telemaco Melia wrote: >> Hi folks, >> >> Sorry to insist but we need to push this forward. >> Can we get consensus soon (today?) about the introduced changes, >> especially section 5.2? >> >> telemaco >> >> Telemaco Melia wrote: >>> Hi all, >>> >>> Please find attached a revised version of the PS document. Comments >>> from people should be hopefully reflected. >>> I told Stefano that a final version for submission will be ready by >>> Friday, so please send comments with proposed text to avoid lengthly >>> discussions. >>> Please pay particular attention to section 5.2 (see Yoshi's email). >>> Also the title of the doc is changed according to Alper's comment >>> (it is in line with the terminology agreed in Prague). >>> >>> cheers, >>> telemaco >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> >>> MIPSHOP T. >>> Melia >>> Internet-Draft >>> NEC >>> Intended status: Informational E. >>> Hepworth >>> Expires: October 27, 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 >>> April 25, >>> 2007 >>> >>> >>> Mobility Services Transport: Problem Statement >>> draft-ietf-mipshop-mis-ps-01 >>> >>> 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 October 27, 2007. >>> >>> Copyright Notice >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 >>> [Page 1] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> Copyright (C) The IETF Trust (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 October 27, 2007 >>> [Page 2] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> Table of Contents >>> >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . >>> . 4 >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . >>> . 4 >>> 3. Definition of Mobility Services . . . . . . . . . . . . . . >>> . 5 >>> 4. Deployment Scenarios for MoS . . . . . . . . . . . . . . . . >>> . 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 . . . . . . . . >>> . 7 >>> 5. MoS Transport Protocol Splitting . . . . . . . . . . . . . . >>> . 8 >>> 5.1. Payload Formats and Extensibility Considerations . . . . >>> . 9 >>> 5.2. Requirements on the Mobility Service Transport Layer . . >>> . 9 >>> 6. Security Considerations . . . . . . . . . . . . . . . . . . >>> . 14 >>> 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . >>> . 15 >>> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . >>> . 15 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . >>> . 16 >>> Intellectual Property and Copyright Statements . . . . . . . . . >>> . 18 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 >>> [Page 3] >>> >>> Internet-Draft Mobility Services Transport April >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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 October 27, 2007 >>> [Page 4] >>> >>> Internet-Draft Mobility Services Transport April >>> 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. >>> >>> >>> 3. Definition of Mobility 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 >>> > Subir>comment; I would say more than just access network > above. Suggestion: Either we delete "(access)" or > add "(access or core)" >>> 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 Services (MoS) having in common different requirements for >>> > Subir> Comment: Do we need both "common" and "different" above? >>> the transport protocol. These requirements and associated >>> functionalities are the focus of this document >>> >>> >>> 4. Deployment Scenarios for MoS >>> >>> 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. >>> >>> 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 the latter case only. > Subir>Suggestion: I would say "the delivery of information for > mobility services" > instead of "delivery of information for MIH services" >>> >>> >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 >>> [Page 5] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> 4.1. End-to-End Signalling and 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 >>> >>> 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. >>> >>> >>> +------+ +------+ +------+ >>> | MN | | NN | | NN | >>> | | | (EP) | | (EP) | >>> +------+ +------+ +------+ >>> Information Exchange >>> <------------------------------------> >>> >>> (Transport over /------------------\ >>> <--------------->< Transport over IP > >>> e.g. L2) \------------------/ >>> >>> Figure 2: Partial Transport >>> >>> >>> >>> >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 >>> [Page 6] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> 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. >>> >>> 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. >>> >>> +------+ +---------+ +------+ >>> | MN | | ProxyNN | | NN | >>> | (EP) | | (EP) | | (EP) | >>> +------+ +---------+ +------+ >>> Information Exchange >>> ------------------> >>> -------------------> >>> <------------------- >>> <------------------ >>> /---------------\ /----------------\ >>> < Transport > < Transport > >>> \---------------/ \----------------/ >>> >>> Figure 3: Information Exchange Approach >>> >>> The Proxy NN might process all layers of the protocol suite in the >>> same way as an ordinary EP. >>> >>> There is a possibility for realizing other proxy scenarios. >>> >>> 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. This is useful for instance in conditions where network >>> components need to take decisions and instruct mobile terminals of >>> operation to be executed. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 >>> [Page 7] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> +------+ +------+ >>> | NN | | NN | >>> | (EP) | | (EP) | >>> +------+ +------+ >>> Information Exchange >>> -------------------> >>> <------------------- >>> >>> /----------------\ >>> < Transport > >>> \----------------/ >>> >>> Figure 4: Information Exchange between different NN >>> >>> Network nodes exchange information about connected terminals status. >>> >>> >>> 5. MoS Transport Protocol Splitting >>> >>> 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). >>> >>> >>> +----------------+ ^ >>> |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 >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 >>> [Page 8] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> 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. 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 >>> >>> 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 > Subir> editorial: add (MSTP) after 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. MSTP does not inspect the payload and any required >>> information will be provided by the MSTP users. >>> >>> 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: Discovery: MNs need the ability to either discover nodes >>> that support certain services, or discover services provided by a >>> certain node. > Subir> comment: why not both node and service discovery? I > understand the service discovery is > not our scope but the first statement is generic. >>> The service discovery can be dealt with messages as >>> defined in [1]. This section refers to node-discovery in either >>> scenario. There are no assumptions about the location of these >>> mobility services within the network, > Subir> editorial: may add "node" after mobility services > above... >>> therefore the discovery >>> mechanism needs to operate across administrative boundaries. >>> Issues such as speed of discovery, protection against spoofing, >>> when discovery needs to take place, and the length of time over >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 >>> [Page 9] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> which the discovery information may remain valid all need to be >>> considered. Approaches include: >>> > Subir> Comment: In general the following approaches fall into > solution category. Do we need > them in the problem statement document? May be I > made this comment earlier. However, > if the group feels that it will improve the > clarity, I am fine. >>> * 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 node, 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. >>> 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. >>> > Subir> editorial: (for example, should the MN look for an "IS" > service, or "IS-local information", and "IS-home > network information" services?) > > >>> 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 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]. The >>> security mechanism must provide mutual authentication of MN >>> and NN >>> and it may provide one way authentication of either of MN and NN. >>> > Subir> The last part of the above sentence is not clear to > me. Are we saying either mutual or one way > authentication? >>> Security association management: A common security association >>> negotiation method, independent of any specific MSTP user, >>> must be >>> implemented. > Subir>comment: I am not sure whether we can say "must be > implemented"? In some cases, security > association may be needed. > suggestion: should is better. Or else, we should > say if SAs are required, it should use the > common one... >>> The solution must also work in case on MN mobility. >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 [Page >>> 10] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> 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). >>> >>> Congestion Control: A Mobility Service may optionally 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 (integrity and confidentiality) between trusted peers, >>> where the transport may pass though untrusted intermediate nodes >>> and networks. The Mobility Service information must also be >>> protected against replay attacks and denial of service attacks. >>> > Subir> comment: 'must' have is too strong here. I am not > sure how easy it will be to prevent > DoS? > Suggestion: 'Should' >>> >>> >>> Melia, et al. Expires October 27, 2007 [Page >>> 11] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> 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. >>> >>> IPv4 and IPv6 support: The MSTP must support both IPv4 and IPv6 >>> including NAT traversal for IPv4 networks and firewall pass- >>> through for IPv4 and IPv6 networks. >>> >>> 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 (see figure >>> Figure 7) . >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 [Page >>> 12] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> +==================================+ >>> | | >>> | +------------+ +-----------+ | >>> | | 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 [Page >>> 13] >>> >>> Internet-Draft Mobility Services Transport April >>> 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. > Subir> comment: How do we conclude the above? The > authorization part is not clear to me. Also > having message authentication is a good idea but > I am not sure if we need to say > 'must' if they are mobile. > suggestion; 'Should' is better. >>> 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. >>> 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. >>> >>> 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 October 27, 2007 [Page >>> 14] >>> >>> Internet-Draft Mobility Services Transport April >>> 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. > Subir> editorial; may change above to "mobility services" > instead of MIH 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/D05.00, April 2007. >>> >>> [2] Aboba, B., "Architectural Implications of Link Indications", >>> draft-iab-link-indications-10 (work in progress), March 2007. >>> >>> [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 October 27, 2007 [Page >>> 15] >>> >>> Internet-Draft Mobility Services Transport April >>> 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: telemaco.melia@netlab.nec.de >>> >>> >>> Eleanor Hepworth >>> Siemens Roke Manor Research >>> Roke Manor >>> Romsey, SO51 5RE >>> UK >>> >>> Email: eleanor.hepworth@roke.co.uk >>> >>> >>> Srivinas Sreemanthula >>> Nokia Research Center >>> 6000 Connection Dr. >>> Irving, TX 75028 >>> USA >>> >>> Email: srinivas.sreemanthula@nokia.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 [Page >>> 16] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> Yoshihiro Ohba >>> Toshiba America Research, Inc. >>> 1 Telcordia Drive >>> Piscateway NJ 08854 >>> USA >>> >>> Email: yohba@tari.toshiba.com >>> >>> >>> Vivek Gupta >>> Intel Corporation >>> 2111 NE 25th Avenue >>> Hillsboro, OR 97124 >>> USA >>> >>> Phone: +1 503 712 1754 >>> Email: vivek.g.gupta@intel.com >>> >>> >>> Jouni Korhonen >>> TeliaSonera Corporation. >>> P.O.Box 970 >>> FIN-00051 Sonera >>> FINLAND >>> >>> Phone: +358 40 534 4455 >>> Email: jouni.korhonen@teliasonera.com >>> >>> >>> Rui L.A. Aguiar >>> Instituto de Telecomunicacoes Universidade de Aveiro >>> Aveiro 3810 >>> Portugal >>> >>> Phone: +351 234 377900 >>> Email: ruilaa@det.ua.pt >>> >>> >>> 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: xiazhongqi@huawei.com >>> >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 [Page >>> 17] >>> >>> Internet-Draft Mobility Services Transport April >>> 2007 >>> >>> >>> Full Copyright Statement >>> >>> Copyright (C) The IETF Trust (2007). >>> >>> This document is subject to the rights, licenses and restrictions >>> contained in BCP 78, and except as set forth therein, the authors >>> retain all their rights. >>> >>> This document and the information contained herein are provided >>> on an >>> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE >>> REPRESENTS >>> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST >>> AND >>> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS >>> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE >>> USE OF >>> THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED >>> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >>> >>> >>> Intellectual Property >>> >>> The IETF takes no position regarding the validity or scope of any >>> Intellectual Property Rights or other rights that might be >>> claimed to >>> pertain to the implementation or use of the technology described in >>> this document or the extent to which any license under such rights >>> might or might not be available; nor does it represent that it has >>> made any independent effort to identify any such rights. >>> Information >>> on the procedures with respect to rights in RFC documents can be >>> found in BCP 78 and BCP 79. >>> >>> Copies of IPR disclosures made to the IETF Secretariat and any >>> assurances of licenses to be made available, or the result of an >>> attempt made to obtain a general license or permission for the >>> use of >>> such proprietary rights by implementers or users of this >>> specification can be obtained from the IETF on-line IPR >>> repository at >>> http://www.ietf.org/ipr. >>> >>> The IETF invites any interested party to bring to its attention any >>> copyrights, patents or patent applications, or other proprietary >>> rights that may cover technology that may be required to implement >>> this standard. Please address the information to the IETF at >>> ietf-ipr@ietf.org. >>> >>> >>> Acknowledgment >>> >>> Funding for the RFC Editor function is provided by the IETF >>> Administrative Support Activity (IASA). >>> >>> >>> >>> >>> >>> Melia, et al. Expires October 27, 2007 [Page >>> 18] >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> MIPSHOP-MIH-DT mailing list >>> MIPSHOP-MIH-DT@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt >>> >> >> >> -- >> Dr. Telemaco Melia telemaco.melia@netlab.nec.de >> Senior Research Staff Member Tel: +49 (0) 6221 4342- 142 >> NEC Europe Ltd. Fax: +49 (0) 6221 4342- 155 >> Network Laboratories Web: http://www.netlab.nec.de >> Kurfuersten-Anlage 36 69115 Heidelberg >> GERMANY >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >> London W3 6BL | Registered in England 2832014 >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> MIPSHOP-MIH-DT mailing list >> MIPSHOP-MIH-DT@ietf.org >> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt >> -- Dr. Telemaco Melia telemaco.melia@netlab.nec.de Senior Research Staff Member Tel: +49 (0) 6221 4342- 142 NEC Europe Ltd. Fax: +49 (0) 6221 4342- 155 Network Laboratories Web: http://www.netlab.nec.de Kurfuersten-Anlage 36 69115 Heidelberg GERMANY NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ MIPSHOP-MIH-DT mailing list MIPSHOP-MIH-DT@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
- [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia
- RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Sam Xia
- RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Robert Hancock
- RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Zuniga, Juan Carlos
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Subir Das
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia
- Re: RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Heejin Jang
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia