Network Working Group J. Korhonen Internet-Draft A. Makela Expires: December 21, 2006 TeliaSonera S. Park SAMSUNG Electronics H. Tschofenig Siemens June 19, 2006 Link and Path Characteristic Information Delivery Analysis draft-korhonen-mobopts-delivery-analysis-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document analyses capabilities and applicability of various IP Mobility, signaling and transport protocols for delivering Link and Path Characteristic Information between communicating end points. Korhonen, et al. Expires December 21, 2006 [Page 1] Internet-Draft LPCI Delivery Analysis June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . 4 3. Candidate Protocols . . . . . . . . . . . . . . . . . . . . . 4 3.1. IP protocol . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. CTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. NSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.7. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.8. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.9. RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.10. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Table of results . . . . . . . . . . . . . . . . . . . . . . . 12 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Results of the Analysis . . . . . . . . . . . . . . . . . 13 5.2. Recommendations for the Information Delivery . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Korhonen, et al. Expires December 21, 2006 [Page 2] Internet-Draft LPCI Delivery Analysis June 2006 1. Introduction Recently mobile nodes are increasingly being equipped with multiple interfaces for different L2 technologies. These mobile nodes may be reachable via different links at the same time or use each interface independently depending on the network environment. In the latter case, transitions between heterogeneous links (vertical handovers) occur. Existing IP mobility solutions do not provide a mechanism to indicate which type of link the mobile node is currently attached to or what kind of characteristics the link has. Therefore, sudden changes of access link characteristics are not observed quickly enough by higher layer protocols and applications. Usually nothing is done until a certain protocol or application dependent mechanism (e.g., congestion control or error recovery mechanism) is invoked some time later when a misuse of the network capacity has been detected. Link Characteristic Information delivery mechanism provides a mechanism to communicate link and path characteristic changes to the remote peer node. This documents lists and analyses various IP Mobility, signaling and transport layer protocols in order to evaluate their suitability for delivering link and path characterisic information between two communicating end points. The analysis should determine whether existing IP Mobility, signaling or transport player protocols can be reused for delivering the LPCI Link and Path Characteristic Information between the communicating end nodes. If existing protocols are not applicable or there is not possible to achieve the information delivery in a reasonable way then the development of a generic protocol should be considered. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Link and Path Characteristic Information (LPCI): An object delivered between communicating end points that contains information about the link or path characteristics. 2. Scope This document concentrates on a limited set of existing candidate protocols for Link Characteristic Information (LPCI) delivery. The suitability of these protocols is evaluated. Korhonen, et al. Expires December 21, 2006 [Page 3] Internet-Draft LPCI Delivery Analysis June 2006 2.1. In Scope Within the scope of this analysis is going through all IP Mobility, signaling and transport protocols listed in Section 3 and carefully verifying whether the protocols are suitable for delivering LPCI between end points. This basically means studying whether each protocol is able to be extended to carry additional payloads related to LPCI. The analysis should also study whether the studied protocol allows delivering the LPCI sporadically without a handover to taking place. This could a useful feature when the link characteristics change considerably mid session even without mobility. An abrupt change, e.g., at the wireless link could justify delivering LPCI to the other peer. For each studied protocol the security aspects must also be taken into account. The LPCI delivery mechanism must not offer off-path adversaries the possibility to inject LPCI. Furthermore, the ability to modify the content by an on-path attacker has to be considered. Finally, a malicious end host must not be able to disturb the behavior of other end hosts. 2.2. Out of Scope Clearly out of scope this analysis document are the mechanisms how the mobile node gathers the LPCI. This document does not describe extensions for carrying LPCI nor does it describe the content of the LPCI. This task is subject for separate documents. 3. Candidate Protocols This section discusses some possible candate protocols to carry a "container" format that could be used with all protocols. o IPv4 - Analyse LPCI delivery using IPv4 header options. There is the risk that IPv4 packets with IP options are dropped by routers. o IPv6 - Analyse LPCI devilery using IPv6 header options. This analysis should also study which option type is the most appropriate to use. Korhonen, et al. Expires December 21, 2006 [Page 4] Internet-Draft LPCI Delivery Analysis June 2006 o SIP - Analyse LPCI delivery using SIP headers o Mobile IPv4 - Analyse LPCI devivery as part of the Mobile IP registration messages options. One of the important aspects is to analyse possible mid-session usage where there is no need to do a registration of new care-of address. o Mobile IPv6 - Analyse LPCI devivery as part of the Mobile IP binding update messages options. One of the important aspects is to analyse possible mid-session usage where there is no need to do a registration of new care-of address. o HIP - Analyse LPCI delivery as part of the HIP base exchange and UPDATE messages after a handover using for example NOTIFY payloads. o NSIS - Analyse LPCI delivery using NSIS mobility signaling with possible required changes to support LPCI. o CTP - Analyse whether CTP could be used for LPCI delivery. o TCP - Analyse LPCI delivery using TCP options. Also take a look into TCP Quick-Start as one possible user of the LPCI information. o DCCP - Analyse LPCI delivery using DCCP options. o SCTP - Analyse LPCI devivery using SCTP chunks. The multi-homing aspect is considered important in case of SCTP. o RTP/RTCP. - Analyse LPCI delivery using RTP and/or RTCP header options. 3.1. IP protocol IP protocol versions 4 [RFC0791] and 6 [RFC2460] are the basic network layer protocols used on The Internet. Both IPv4 and IPv6 provide an "options" field where a single option has a limitation of 256 octets total length. IPv6 provides more flexibility in option handling, as separate option classes exist for options that need to be examined by all intermediate nodes on a path or only at the destination. IPv4 options have no such classification, and options are checked at all nodes. Because there is no separate class for end-to-end options, all intermediate nodes have to examine all options; Due to performance reasons such options are often filtered and do not reliably reach destination. Furthermore, intermediate nodes tend to drop IPv4 packets with options they do not understand [MAF04]. Korhonen, et al. Expires December 21, 2006 [Page 5] Internet-Draft LPCI Delivery Analysis June 2006 3.2. SIP Session initiation protocol [RFC3261] is a protocol with the explicit purpose of setting up sessions. The actual data protocol communication is separate from the set-up. As such, any LPCI information transferred over SIP would be used as initial parameters for the session and, if applicable, subsequently as updates to the session. Sessions that are set up are described using Session description protocol, or SDP [RFC2327]. The SDP parameters are pure text, and include such variables as the session protocol to be used, protocol ports, IP addresses, session participants and so on. LPCI information for a session can be carried inside SDP as an extra parameter. SIP information can be transferred via several proxies, and information about specific potential participant can be registered to SIP registrars, allowing for delegation of LPCI information. 3.3. Mobile IP Mobile IPv4 [RFC3344] provides a general protocol support for a IPv4 mobile node to register its current location with the Home Agent and in that way create or update the mobility binding between mobile node's current care-of-address and the Home Agent. The used Mobile IPv4 registration messages offer a general extensibility mechanism. Extension parameters are also integrity protected. The mobile node may also send the registration request at any time even if there is no handover taking place. The recent addition of the NAT traversal allows mobile nodes communicating behind NATs. The same NAT traversal mechanism also allows mobile nodes to communicate fluently through statefull firewalls even if the original goal was to allow NATs in visited networks. Unfortunately, base Mobile IPv4 only provides a mechanism to exchange Mobile IPv4 control messages between the mobile node and the foreign agent or between the mobile node and the home agent. The lack of route optimization in base Mobile IPv4 prevents mobile nodes exchanging any control messages directly between the mobile node and the correspondent node or even between the home agent and the correspondent node. In contrast to Mobile IPv4, Mobile IPv6 [RFC3775] provides a route optimization feature as an integral feature of the base specification that allows the mobile node to send its mobility binding directly to the correspondent node. After a successful route optimization Korhonen, et al. Expires December 21, 2006 [Page 6] Internet-Draft LPCI Delivery Analysis June 2006 binding update the mobile node and the correspondent node start communicating directly end-to-end with each other. The route optimization is an optional feature and mobile nodes are not obligated to use it. 3.4. CTP Context transfer protocol [RFC4067] is a protocol designed to expedite handovers for a mobile node. It allows "contexts" to be transferred from the mobile node's current access router to new access router before the handover. If a break-before-make handover occurs, the new access router can also request the context transfer from the previous one afterwards. An example of "context" is multicast listerer information, where transferring the information lowers the cost of the handover considerably. CTP uses ICMP messages between the mobile node and the access router, and SCTP between access routers. Because CTP is always a separate message, LPCI messages could be bundled inside a CTP message that is going to be sent anyway (i.e. when changing access routers). However, when link information changes without access router changing, (Such as when roaming from 3G to GPRS), every CTP message is causing significant load on the network. Thus it may fail requirement R5 for lightweight operation. 3.5. HIP The Host Identity Protocol [RFC4423] creates a new cryptographic namespace placed between the transport and the network layer. One of the extensions defined for HIP concerns mobility and multi-homing [I-D.ietf-hip-mm]. When a host moves to another address, it notifies its peer of the new address by sending a HIP UPDATE packet containing a LOCATOR parameter. This UPDATE packet is then acknowledged by the peer. LPCI can be exchanged as part of the UPDATE packet. 3.6. NSIS Next Steps in Signaling protocol suite (see GIST [I-D.ietf-nsis- ntlp], QoS NSLP [I-D.ietf-nsis-qos-nslp], NATFW NSLP [I-D.ietf-nsis- nslp-natfw] and an overview of the framework in [RFC4080]) aims to provide a generic signaling protocol. One of the applications, such as the QoS NSLP, allows QoS signaling message to be carried between two end points and to let intermediate routers to participate along Korhonen, et al. Expires December 21, 2006 [Page 7] Internet-Draft LPCI Delivery Analysis June 2006 the path. NSIS offers functionality similar to RSVP, but aims to be more generic and covers more usage environments. When designing a solution using NSIS three cases need to be considered. If the data sender moves (or switches to a different link layer interace) then the impact will most likely be at the side of the data sender. If the data receiver moves (or switches to a different link layer interace) then the impact will most likely be at the side of the data receiver. In some cases (e.g., due to network mobility or rerouting events) the impact might be somewhere along the path independent from the end points. If NSIS is used for E2E QoS signaling then the additional functionality is minimal since NSIS interworking with mobility and multi-homing is required for NSIS and already provided. For a discussion of the problems and the solutions the reader is referred to [I-D.ietf-nsis-applicability-mobility-signaling]. For a data sender there is no problem to trigger a new NSIS signaling exchange. The exchange is shown in the subsequent figure whereby only a single intermediate node is depicted for editorial reasons: MN Node CN (Sender) (Receiver) | | | | LPCI - QUERY | | +------------------------------->| QUERY | | +--------->| | | RESPONSE | | RESPONSE |<---------+ |<-------------------------------+ | | | | When the data sender (MN) roams or changes the interface then a LPCI QUERY message is sent to collect path characteristics. When the data receiver (CN) receives the message it returns a RESPONSE message and thereby provides the learned path characteristics back to the MN. Due to routing asymmetry the same approach cannot be used by the data receiver when the problem is detected there first. The message exchange then has to start with a trigger based on MIP or NSIS as shown in the following figure: Korhonen, et al. Expires December 21, 2006 [Page 8] Internet-Draft LPCI Delivery Analysis June 2006 MN Node CN (Receiver) (Sender) | | | | NOTIFICATION | | |------------------------------------------>| | | | | | QUERY | | LPCI - QUERY |<---------+ |<-------------------------------+ | | | | | RESPONSE | | +------------------------------->| RESPONSE | | +--------->| | | | | | | The first message aims to show a notification message that causes the data sender to initiate a LPCI QUERY message as shown in the previous message. Problems within the middle of the network are detected with period QUERY/RESPONSE message exchange. When QoS signaling is not desired, as in the case of LPCI exchange, then a new NSLP is needed. The support for LPCI nodes can be incrementally deployed, starting in environments such as access networks and moving networks. Such an NSIS LPCI NSLP can therefore consider path instead of only link characteristics resulting in a more robust solution. Note that the LPCI QUERY / RESPONSE message exchange does not need to create state to be allocated at intermediate devices. 3.7. TCP Transmission control protocol [RFC0793] guarantees reliable and in- order delivery of sender to receiver data. TCP session is set up via a three-way handshake, and packet order and reliability is maintained by sequence numbers and sliding window acknowledgements. Congestion is handled via mechanisms such as slow start and explicit notifications. Since it's original introduction, TCP has been extended on multiple occasions, as the protocol provides a variable-length "options" field. The options have been used to transmit such information as window scaling factor and timestamps for RTT measurements. Adding a new option for LPCI is trivial. Korhonen, et al. Expires December 21, 2006 [Page 9] Internet-Draft LPCI Delivery Analysis June 2006 To lower information traversal, TCP's URG flag should be set for packets containing LPCI data, so that applications can react accordingly with minimal delay. 3.8. DCCP The Datagram Congestion Control Protocol (DCCP) [RFC4340]is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is intended for applications such as streaming media that can benefit from control over the tradeoffs between delay and reliable in-order delivery. DCCP does not contain support for mobility or multihoming anymore. Mobility and multihoming are now defined as an option in a sepatare document [I-D.kohler-dccp-mobility]. Each DCCP connection was associated with exactly two network-level addresses over its lifetime, one per endpoint. There is one potential design for DCCP mobility and multihoming support. DCCP mobility and multihoming support is based on generalized connections. A generalized connection groups one or more transport connections, called component connections, into a single application- level entity. To move addresses, a host attaches a new component connection, then detaches the old component connection. The first connection handshake in a generalized connection must register the intention to set up a generalized connection. The generalized connection's identifier is then agreed upon by the two endpoints (assuming they both support mobility). Thereafter, new component connections specify the intended generalized connection in their handshakes. Even though there is one potential mechanism for DCCP Mobility which makes a new component connection and destroys a old component connection with congestion control, it has many problems to guarantee quality-of-service, such as packet loss, jitter ,out of sequence packets and so on. Mobile networks with many participants and poor network resources cause a DCCP packet delays. This fact indicates that DCCP may not be satisfactory for LPCI delivery. DCCP is not currently in wide use. 3.9. RTP/RTCP RTP protocol [RFC3550] provides end-to-end transport functions suitable for applications transmitting real-time data, such as audio and video, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. RTP is augmented by a control protocol (RTCP) to monitor data delivery and network statistics. Korhonen, et al. Expires December 21, 2006 [Page 10] Internet-Draft LPCI Delivery Analysis June 2006 RTCP packets are transmitted periodically to all participants in the session to provide feedback on the quality of the data distribution as the form of Sender Report (SR) or Receiver Report (RR). All participants send RTCP packets, therefore the interval of sending RTCP packet must be controlled in order for RTP to scale up to a large number of participants. This is an integral part of the RTP's role as a transport protocol and is related to the flow and congestion control. Although RTCP resolves many of the problems in UDP network environment, such as lost packets, jitter, and out of sequence packets, it that reports conditions of session periodically may have difficulty to guarantee quality-of-service immediately. Mobile environments with many participants and low bandwidth may cause the long interval of RTCP transmission (e.g., five, six seconds or more). Although there is more immediate RTCP feedback (defined in 'Extended RTP profile for RTCP-based Feedback'), RTCP feedback message is heavy to send LPCI. As RTCP feedback message is added the end of normal RTCP packet, it may send unnecessary information in addition to the LPCI. Moreover, RTCP feedback message is hard to respond immediately when the receiver is in the large group. The previously discussed issues are more a problem of RTP itself with a large receiver group than a LPCI specific issue. Therefore, RTP and RTCP might not be appropriate for the LPCI delivery without resolving above problems first, late and inefficient Link and Path Characteristic Information delivery. 3.10. SCTP SCTP [RFC2960] is a general-purpose transport layer protocol. SCTP provides features such as multi-streaming and multi-homing that may be helpful in mobility environment. SCTP's current multi-homing allows two end-points to set up an association with multiple IP address for each endpoint. Retransmission of lost packets can be done over the secondary path. Mobile SCTP is able to provide a solution for limited mobility scenarios as well. A multi-access user would be able to roam between heterogeneous access networks without breaking any existing connections. A new connection for the same session can be initialized with separate parameters (congestion window size, mtu ,etc.) As SCTP originally does not provide QoS support, extensions may be needed for expedited LPCI delivery. It should be able to implement LPCI delivery by extending ASCONF chunk message for dynamic address configuration or by making suggestion of new chunk. SCTP is not currently in wide use. Korhonen, et al. Expires December 21, 2006 [Page 11] Internet-Draft LPCI Delivery Analysis June 2006 4. Table of results Results are presented in the following tables: +-----------+-----+-----+-----+-----+---------+---------+-----+ | Protocol | R1 | R2 | R3 | R4 | R5 | R6 | R7 | +-----------+-----+-----+-----+-----+---------+---------+-----+ | IP | N/A | N/A | Yes | Yes | Var [1] | yes | N/A | | SIP | N/A | N/A | Yes | Yes | Yes | N/A | N/A | | Mobile IP | Yes | Yes | Yes | Yes | Var [7] | Yes [5] | Yes | | CTP | Yes | Yes | Yes | Yes | Var [7] | N/A | N/A | | HIP | Yes | Yes | Yes | Yes | Var [7] | Yes | Yes | | NSIS | Yes | Yes | Yes | Yes | Var[10] | Yes | Yes | | TCP | N/A | N/A | Yes | Yes | Yes | No | Yes | | DCCP | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | RTP/RTCP | N/A | N/A | Yes | Yes | Var [7] | Yes | Yes | | SCTP | Yes | Yes | Yes | Yes | Yes | Yes | Yes | +-----------+-----+-----+-----+-----+---------+---------+-----+ Table 1 +-----------+-----+-----+-----+---------+----------+---------+-----+ | Protocol | R8 | R9 | R10 | R11 | R12 | R13 | R14 | +-----------+-----+-----+-----+---------+----------+---------+-----+ | IP | Yes | Yes | Yes | See [2] | N/A | N/A | N/A | | SIP | Yes | Yes | Yes | Yes [3] | Yes [4] | N/A | N/A | | Mobile IP | N/A | Yes | Yes | Yes | Yes | Yes [6] | Yes | | CTP | N/A | Yes | Yes | Yes | Yes | Yes | Yes | | HIP | N/A | Yes | Yes | Yes | Yes(RVS) | Yes | Yes | | NSIS | Yes | Yes | Yes | Yes | Yes | Yes[11] | Yes | | TCP | Yes | Yes | Yes | Yes | No | Yes | Yes | | DCCP | Yes | Yes | Yes | Var [9] | No | No QoS | Yes | | RTP/RTCP | Yes | Yes | Yes | Yes | No [4] | No [8] | Yes | | SCTP | Yes | Yes | Yes | Var [9] | No | No QoS | Yes | +-----------+-----+-----+-----+---------+----------+---------+-----+ Table 2 [1] Load depends of implementation option handling. Options have to be examined at every node on the path, except in the case of IPv6 Destination Options. [2] NAT's and firewalls generally handle traversal based on 4-tuple of IP addresses and source and destination ports. Also, IPv4 headers may be removed at the intermediate nodes due to lack of classification between end-to-end and hop-by-hop options. [3] SIP traverses through firewalls, but the session that will be set Korhonen, et al. Expires December 21, 2006 [Page 12] Internet-Draft LPCI Delivery Analysis June 2006 up as a follow-up requires explicit support from the firewall (SIP ALG) or other mechanisms, such as STUN. [4] Delegation via SIP proxies or other mechanisms possible. [5] MIP supports multiple care-of-addresses. [6] Preregistering new care-of-address before deregistering the next allows for seamless handovers. The new care-of-address registration can contain new LPCI values. [7] Explicit messages for ONLY the LPCI data increases signaling load; If LPCI data can be bundled with other (necessary) signaling, load increase is minimal. [8] RTCP message sending delay may grow too large for the information to lose it's significance. Using explicit notifications contradicts R5. [9] Protocol is relatively new, so support in firewalls and NAT equipment is still emerging and not widely available. [10] NSIS as an out-of-band mechanism is naturally more heavy-weight than an in-band mechanism. The total amount of overhead depends, however, on a number of factors. Details can be determined from [nsis-performance-paper]. [11] NSIS needs to be triggered at the new point of attachment while the mobile node is still at the old point of attachment. This is possible in a mobility environment but introduces complexity. 5. Conclusions 5.1. Results of the Analysis The results of the analysis are that most of the protocols can technically transport the LPCI attributes; i.e. they have a freely- definable option-field or similar structure. However, other constraints may impact feasibility of individual protocols. The primary concern is that the LCI information should not cause too much additional signaling load to the network, and the information should still be of value upon reaching destination. Most transport protocols implement some sort of congestion and flow control, which will cause delay in sending LPCI information 'bundled' with normal flow of information. On the other hand, explicit notification mechanisms will increase load significantly. For example, a single Korhonen, et al. Expires December 21, 2006 [Page 13] Internet-Draft LPCI Delivery Analysis June 2006 option field in a TCP acknowledgement packet increases the load with a few bytes; but an explicit notification in a separate IP packet (such as the RTP notification mechanism) will require an entire additional packet to be constructed and sent. 5.2. Recommendations for the Information Delivery The most problematic situation is a break-before-make handover from a high-speed link to low-speed link. If high bandwidth is available, the additional load caused by explicit notifications are not such a significant issue; even in a make-before-break situation (predictive handover) most of the additional load can be sent on the high-speed link before the handover occurs. After such a handover, the following recommendations can be made: o Use a delegation mechanism, if possible, such as Mobile IP Home agent to make the notifications to peer nodes, to avoid extra load on the final link. o If delegation is not possible, include the LCI data inside standard session packets, such as TCP acknowledgements (packets that would be sent regardless) or Mobile IP path optimization binding update. o Have peers reuse the information; If having multiple sessions with a single host, send the LCI information only once and have it concern all the sessions. The LPCI delivery solution SHOULD be a generic container that can be transferred over any transport protocol. Individual transport protocols MAY use protocol-specific derivations for eg. data compression, but such specifics are beyond the scope of this document. 6. IANA Considerations This document does not require actions by IANA. 7. Security Considerations Security requirements for the delivery of LPCI have been mentioned in [I-D.korhonen-mobopts-link-characteristics-ps]. This document lists a number of candidate protocols whereby each protocol offers different security properties. A security analysis has to be provided for each protocol. Korhonen, et al. Expires December 21, 2006 [Page 14] Internet-Draft LPCI Delivery Analysis June 2006 8. Acknowledgments Special thanks to Yunju Choe (contributor of RTP section), Jeongrok Jang (contributor of DCCP section) and Minho Lee (contributor of SCTP section) for their valuable contributions. 9. References 9.1. Normative References [I-D.korhonen-mobopts-link-characteristics-ps] Korhonen, J., "Link Characteristic Information for IP Mobility Problem Statement", draft-korhonen-mobopts-link-characteristics-ps-01 (work in progress), June 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.ietf-hip-mm] Nikander, P., "End-Host Mobility and Multihoming with the Host Identity Protocol", draft-ietf-hip-mm-03 (work in progress), March 2006. [I-D.ietf-nsis-applicability-mobility-signaling] Lee, S., "Applicability Statement of NSIS Protocols in Mobile Environments", draft-ietf-nsis-applicability-mobility-signaling-04 (work in progress), March 2006. [I-D.ietf-nsis-nslp-natfw] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-11 (work in progress), April 2006. [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", draft-ietf-nsis-ntlp-09 (work in progress), February 2006. [I-D.ietf-nsis-qos-nslp] Manner, J., "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-10 (work in progress), March 2006. Korhonen, et al. Expires December 21, 2006 [Page 15] Internet-Draft LPCI Delivery Analysis June 2006 [I-D.kohler-dccp-mobility] Kohler, E., "Datagram Congestion Control Protocol Mobility and Multihoming", draft-kohler-dccp-mobility-01 (work in progress), January 2006. [MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes, in Internet Measurement Conference 2004", August 2004. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. Korhonen, et al. Expires December 21, 2006 [Page 16] Internet-Draft LPCI Delivery Analysis June 2006 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [nsis-performance-paper] Fu, X., Hogrefe, D., Schulzrinne, H., Tschofenig, H., and C. Dickmann, "Overhead and Performance Study of the General Internet Signaling Transport (GIST) Protocol, in IEEE INFOCOM 2006, Bacelona, Spain, IEEE", April 2006. Korhonen, et al. Expires December 21, 2006 [Page 17] Internet-Draft LPCI Delivery Analysis June 2006 Authors' Addresses Jouni Korhonen TeliaSonera Corporation. P.O.Box 970 FIN-00051 Sonera FINLAND Phone: +358 40 534 4455 Email: jouni.korhonen@teliasonera.com Antti Makela TeliaSonera Corporation. P.O.Box 777 FIN-33101 Tampere FINLAND Phone: +358 40 824 4170 Email: antti.makela@teliasonera.com Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics. 416 Maetan-3dong, Yeongtong-gu Suwon, Gyeonggi-do 443-742 KOREA Phone: +82 31 200 4508 Email: soohong.park@samsung.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com Korhonen, et al. Expires December 21, 2006 [Page 18] Internet-Draft LPCI Delivery Analysis June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Korhonen, et al. Expires December 21, 2006 [Page 19]