idnits 2.17.1 draft-korhonen-mobopts-delivery-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 800. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 824. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 6395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 540 -- Looks like a reference, but probably isn't: '7' on line 561 -- Looks like a reference, but probably isn't: '5' on line 555 -- Looks like a reference, but probably isn't: '10' on line 572 -- Looks like a reference, but probably isn't: '2' on line 544 -- Looks like a reference, but probably isn't: '3' on line 549 -- Looks like a reference, but probably isn't: '4' on line 553 -- Looks like a reference, but probably isn't: '6' on line 557 -- Looks like a reference, but probably isn't: '11' on line 577 -- Looks like a reference, but probably isn't: '9' on line 569 -- Looks like a reference, but probably isn't: '8' on line 565 == Unused Reference: 'RFC4340' is defined on line 737, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-04 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-applicability-mobility-signaling-05 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-12 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-11 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-11 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Korhonen 3 Internet-Draft A. Makela 4 Intended status: Informational TeliaSonera 5 Expires: April 26, 2007 S. Park 6 SAMSUNG Electronics 7 H. Tschofenig 8 Siemens 9 October 23, 2006 11 Link and Path Characteristic Information Delivery Analysis 12 draft-korhonen-mobopts-delivery-analysis-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 26, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document analyses capabilities and applicability of various IP 46 Mobility, signaling and transport protocols for delivering Link and 47 Path Characteristic Information between communicating end points. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Candidate Protocols . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. IP protocol . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.4. CTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.5. HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.6. NSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.7. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.8. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.9. RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.10. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4. Table of results . . . . . . . . . . . . . . . . . . . . . . . 12 68 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.1. Results of the Analysis . . . . . . . . . . . . . . . . . 13 70 5.2. Recommendations for the Information Delivery . . . . . . . 14 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 78 Intellectual Property and Copyright Statements . . . . . . . . . . 19 80 1. Introduction 82 Recently mobile nodes are increasingly being equipped with multiple 83 interfaces for different L2 technologies. These mobile nodes may be 84 reachable via different links at the same time or use each interface 85 independently depending on the network environment. In the latter 86 case, transitions between heterogeneous links (vertical handovers) 87 occur. Existing IP mobility solutions do not provide a mechanism to 88 indicate which type of link the mobile node is currently attached to 89 or what kind of characteristics the link has. Therefore, sudden 90 changes of access link characteristics are not observed quickly 91 enough by higher layer protocols and applications. Usually nothing 92 is done until a certain protocol or application dependent mechanism 93 (e.g., congestion control or error recovery mechanism) is invoked 94 some time later when a misuse of the network capacity has been 95 detected. Link Characteristic Information delivery mechanism 96 provides a mechanism to communicate link and path characteristic 97 changes to the remote peer node. 99 This documents lists and analyses various IP Mobility, signaling and 100 transport layer protocols in order to evaluate their suitability for 101 delivering link and path characteristic information between two 102 communicating end points. The analysis should determine whether 103 existing IP Mobility, signaling or transport player protocols can be 104 reused for delivering the LPCI Link and Path Characteristic 105 Information between the communicating end nodes. If existing 106 protocols are not applicable or there is not possible to achieve the 107 information delivery in a reasonable way then the development of a 108 generic protocol should be considered. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 Link and Path Characteristic Information (LPCI): 118 An object delivered between communicating end points that contains 119 information about the link or path characteristics. 121 2. Scope 123 This document concentrates on a limited set of existing candidate 124 protocols for Link Characteristic Information (LPCI) delivery. The 125 suitability of these protocols is evaluated. 127 2.1. In Scope 129 Within the scope of this analysis is going through all IP Mobility, 130 signaling and transport protocols listed in Section 3 and carefully 131 verifying whether the protocols are suitable for delivering LPCI 132 between end points. This basically means studying whether each 133 protocol is able to be extended to carry additional payloads related 134 to LPCI. 136 The analysis should also study whether the studied protocol allows 137 delivering the LPCI sporadically without a handover to taking place. 138 This could a useful feature when the link characteristics change 139 considerably mid session even without mobility. An abrupt change, 140 e.g., at the wireless link could justify delivering LPCI to the other 141 peer. 143 For each studied protocol the security aspects must also be taken 144 into account. The LPCI delivery mechanism must not offer off-path 145 adversaries the possibility to inject LPCI. Furthermore, the ability 146 to modify the content by an on-path attacker has to be considered. 147 Finally, a malicious end host must not be able to disturb the 148 behavior of other end hosts. 150 2.2. Out of Scope 152 Clearly out of scope this analysis document are the mechanisms how 153 the mobile node gathers the LPCI. 155 This document does not describe extensions for carrying LPCI nor does 156 it describe the content of the LPCI. This task is subject for 157 separate documents. 159 3. Candidate Protocols 161 This section discusses some possible candidate protocols to carry a 162 "container" format that could be used with all protocols. 164 o IPv4 - Analyze LPCI delivery using IPv4 header options. There is 165 the risk that IPv4 packets with IP options are dropped by routers. 167 o IPv6 - Analyze LPCI delivery using IPv6 header options. This 168 analysis should also study which option type is the most 169 appropriate to use. 171 o SIP - Analyze LPCI delivery using SIP headers 173 o Mobile IPv4 - Analyze LPCI delivery as part of the Mobile IP 174 registration messages options. One of the important aspects is to 175 analyze possible mid-session usage where there is no need to do a 176 registration of new care-of address. 178 o Mobile IPv6 - Analyze LPCI delivery as part of the Mobile IP 179 binding update messages options. One of the important aspects is 180 to analyse possible mid-session usage where there is no need to do 181 a registration of new care-of address. 183 o HIP - Analyze LPCI delivery as part of the HIP base exchange and 184 UPDATE messages after a handover using for example NOTIFY 185 payloads. 187 o NSIS - Analyze LPCI delivery using NSIS mobility signaling with 188 possible required changes to support LPCI. 190 o CTP - Analyze whether CTP could be used for LPCI delivery. 192 o TCP - Analyze LPCI delivery using TCP options. Also take a look 193 into TCP Quick-Start as one possible user of the LPCI information. 195 o DCCP - Analyze LPCI delivery using DCCP options. 197 o SCTP - Analyze LPCI delivery using SCTP chunks. The multi-homing 198 aspect is considered important in case of SCTP. 200 o RTP/RTCP. - Analyze LPCI delivery using RTP and/or RTCP header 201 options. 203 3.1. IP protocol 205 IP protocol versions 4 [RFC0791] and 6 [RFC2460] are the basic 206 network layer protocols used on The Internet. Both IPv4 and IPv6 207 provide an "options" field where a single option has a limitation of 208 256 octets total length. IPv6 provides more flexibility in option 209 handling, as separate option classes exist for options that need to 210 be examined by all intermediate nodes on a path or only at the 211 destination. IPv4 options have no such classification, and options 212 are checked at all nodes. Because there is no separate class for 213 end-to-end options, all intermediate nodes have to examine all 214 options; Due to performance reasons such options are often filtered 215 and do not reliably reach destination. Furthermore, intermediate 216 nodes tend to drop IPv4 packets with options they do not understand 217 [MAF04]. 219 3.2. SIP 221 Session initiation protocol [RFC3261] is a protocol with the explicit 222 purpose of setting up sessions. The actual data protocol 223 communication is separate from the set-up. As such, any LPCI 224 information transferred over SIP would be used as initial parameters 225 for the session and, if applicable, subsequently as updates to the 226 session. 228 Sessions that are set up are described using Session description 229 protocol, or SDP [RFC2327]. The SDP parameters are pure text, and 230 include such variables as the session protocol to be used, protocol 231 ports, IP addresses, session participants and so on. LPCI 232 information for a session can be carried inside SDP as an extra 233 parameter. 235 SIP information can be transferred via several proxies, and 236 information about specific potential participant can be registered to 237 SIP registrars, allowing for delegation of LPCI information. 239 3.3. Mobile IP 241 Mobile IPv4 [RFC3344] provides a general protocol support for a IPv4 242 mobile node to register its current location with the Home Agent and 243 in that way create or update the mobility binding between mobile 244 node's current care-of-address and the Home Agent. The used Mobile 245 IPv4 registration messages offer a general extensibility mechanism. 246 Extension parameters are also integrity protected. 248 The mobile node may also send the registration request at any time 249 even if there is no handover taking place. The recent addition of 250 the NAT traversal allows mobile nodes communicating behind NATs. The 251 same NAT traversal mechanism also allows mobile nodes to communicate 252 fluently through statefull firewalls even if the original goal was to 253 allow NATs in visited networks. 255 Unfortunately, base Mobile IPv4 only provides a mechanism to exchange 256 Mobile IPv4 control messages between the mobile node and the foreign 257 agent or between the mobile node and the home agent. The lack of 258 route optimization in base Mobile IPv4 prevents mobile nodes 259 exchanging any control messages directly between the mobile node and 260 the correspondent node or even between the home agent and the 261 correspondent node. 263 In contrast to Mobile IPv4, Mobile IPv6 [RFC3775] provides a route 264 optimization feature as an integral feature of the base specification 265 that allows the mobile node to send its mobility binding directly to 266 the correspondent node. After a successful route optimization 267 binding update the mobile node and the correspondent node start 268 communicating directly end-to-end with each other. The route 269 optimization is an optional feature and mobile nodes are not 270 obligated to use it. 272 3.4. CTP 274 Context transfer protocol [RFC4067] is a protocol designed to 275 expedite handovers for a mobile node. It allows "contexts" to be 276 transferred from the mobile node's current access router to new 277 access router before the handover. If a break-before-make handover 278 occurs, the new access router can also request the context transfer 279 from the previous one afterwards. 281 An example of "context" is multicast listener information, where 282 transferring the information lowers the cost of the handover 283 considerably. 285 CTP uses ICMP messages between the mobile node and the access router, 286 and SCTP between access routers. Because CTP is always a separate 287 message, LPCI messages could be bundled inside a CTP message that is 288 going to be sent anyway (i.e. when changing access routers). 289 However, when link information changes without access router 290 changing, (Such as when roaming from 3G to GPRS), every CTP message 291 is causing significant load on the network. Thus it may fail 292 requirement R5 for lightweight operation. 294 3.5. HIP 296 The Host Identity Protocol [RFC4423] creates a new cryptographic 297 namespace placed between the transport and the network layer. One of 298 the extensions defined for HIP concerns mobility and multi-homing 299 [I-D.ietf-hip-mm]. 301 When a host moves to another address, it notifies its peer of the new 302 address by sending a HIP UPDATE packet containing a LOCATOR 303 parameter. This UPDATE packet is then acknowledged by the peer. 304 LPCI can be exchanged as part of the UPDATE packet. 306 3.6. NSIS 308 Next Steps in Signaling protocol suite (see GIST 309 [I-D.ietf-nsis-ntlp], QoS NSLP [I-D.ietf-nsis-qos-nslp], NATFW NSLP 310 [I-D.ietf-nsis-nslp-natfw] and an overview of the framework in 311 [RFC4080]) aims to provide a generic signaling protocol. One of the 312 applications, such as the QoS NSLP, allows QoS signaling message to 313 be carried between two end points and to let intermediate routers to 314 participate along the path. NSIS offers functionality similar to 315 RSVP, but aims to be more generic and covers more usage environments. 317 When designing a solution using NSIS three cases need to be 318 considered. If the data sender moves (or switches to a different 319 link layer interface) then the impact will most likely be at the side 320 of the data sender. If the data receiver moves (or switches to a 321 different link layer interface) then the impact will most likely be 322 at the side of the data receiver. In some cases (e.g., due to 323 network mobility or rerouting events) the impact might be somewhere 324 along the path independent from the end points. 326 If NSIS is used for E2E QoS signaling then the additional 327 functionality is minimal since NSIS inter-working with mobility and 328 multi-homing is required for NSIS and already provided. For a 329 discussion of the problems and the solutions the reader is referred 330 to [I-D.ietf-nsis-applicability-mobility-signaling]. For a data 331 sender there is no problem to trigger a new NSIS signaling exchange. 332 The exchange is shown in the subsequent figure whereby only a single 333 intermediate node is depicted for editorial reasons: 335 MN Node CN 336 (Sender) (Receiver) 337 | | | 338 | LPCI - QUERY | | 339 +------------------------------->| QUERY | 340 | +--------->| 341 | | RESPONSE | 342 | RESPONSE |<---------+ 343 |<-------------------------------+ | 344 | | | 346 When the data sender (MN) roams or changes the interface then a LPCI 347 QUERY message is sent to collect path characteristics. When the data 348 receiver (CN) receives the message it returns a RESPONSE message and 349 thereby provides the learned path characteristics back to the MN. 351 Due to routing asymmetry the same approach cannot be used by the data 352 receiver when the problem is detected there first. The message 353 exchange then has to start with a trigger based on MIP or NSIS as 354 shown in the following figure: 356 MN Node CN 357 (Receiver) (Sender) 358 | | | 359 | NOTIFICATION | | 360 |------------------------------------------>| 361 | | | 362 | | QUERY | 363 | LPCI - QUERY |<---------+ 364 |<-------------------------------+ | 365 | | | 366 | RESPONSE | | 367 +------------------------------->| RESPONSE | 368 | +--------->| 369 | | | 370 | | | 372 The first message aims to show a notification message that causes the 373 data sender to initiate a LPCI QUERY message as shown in the previous 374 message. 376 Problems within the middle of the network are detected with period 377 QUERY/RESPONSE message exchange. 379 When QoS signaling is not desired, as in the case of LPCI exchange, 380 then a new NSLP is needed. The support for LPCI nodes can be 381 incrementally deployed, starting in environments such as access 382 networks and moving networks. Such an NSIS LPCI NSLP can therefore 383 consider path instead of only link characteristics resulting in a 384 more robust solution. Note that the LPCI QUERY / RESPONSE message 385 exchange does not need to create state to be allocated at 386 intermediate devices. 388 3.7. TCP 390 Transmission control protocol [RFC0793] guarantees reliable and in- 391 order delivery of sender to receiver data. 393 TCP session is set up via a three-way handshake, and packet order and 394 reliability is maintained by sequence numbers and sliding window 395 acknowledgements. Congestion is handled via mechanisms such as slow 396 start and explicit notifications. 398 Since it's original introduction, TCP has been extended on multiple 399 occasions, as the protocol provides a variable-length "options" 400 field. The options have been used to transmit such information as 401 window scaling factor and timestamps for RTT measurements. Adding a 402 new option for LPCI is trivial. 404 To lower information traversal, TCP's URG flag should be set for 405 packets containing LPCI data, so that applications can react 406 accordingly with minimal delay. 408 3.8. DCCP 410 The Datagram Congestion Control Protocol (DCCP) [RFC4340]is a 411 transport protocol that provides bidirectional unicast connections of 412 congestion-controlled unreliable datagrams. DCCP is intended for 413 applications such as streaming media that can benefit from control 414 over the tradeoffs between delay and reliable in-order delivery. 415 DCCP does not contain support for mobility or multihoming anymore. 416 Mobility and multihoming are now defined as an option in a separate 417 document [I-D.kohler-dccp-mobility]. Each DCCP connection was 418 associated with exactly two network-level addresses over its 419 lifetime, one per endpoint. There is one potential design for DCCP 420 mobility and multihoming support. 422 DCCP mobility and multihoming support is based on generalized 423 connections. A generalized connection groups one or more transport 424 connections, called component connections, into a single application- 425 level entity. To move addresses, a host attaches a new component 426 connection, then detaches the old component connection. The first 427 connection handshake in a generalized connection must register the 428 intention to set up a generalized connection. The generalized 429 connection's identifier is then agreed upon by the two endpoints 430 (assuming they both support mobility). Thereafter, new component 431 connections specify the intended generalized connection in their 432 handshakes. 434 Even though there is one potential mechanism for DCCP Mobility which 435 makes a new component connection and destroys a old component 436 connection with congestion control, it has many problems to guarantee 437 quality-of-service, such as packet loss, jitter ,out of sequence 438 packets and so on. Mobile networks with many participants and poor 439 network resources cause a DCCP packet delays. This fact indicates 440 that DCCP may not be satisfactory for LPCI delivery. 442 DCCP is not currently in wide use. 444 3.9. RTP/RTCP 446 RTP protocol [RFC3550] provides end-to-end transport functions 447 suitable for applications transmitting real-time data, such as audio 448 and video, over multicast or unicast network services. RTP does not 449 address resource reservation and does not guarantee quality-of- 450 service for real-time services. RTP is augmented by a control 451 protocol (RTCP) to monitor data delivery and network statistics. 453 RTCP packets are transmitted periodically to all participants in the 454 session to provide feedback on the quality of the data distribution 455 as the form of Sender Report (SR) or Receiver Report (RR). All 456 participants send RTCP packets, therefore the interval of sending 457 RTCP packet must be controlled in order for RTP to scale up to a 458 large number of participants. This is an integral part of the RTP's 459 role as a transport protocol and is related to the flow and 460 congestion control. 462 Although RTCP resolves many of the problems in UDP network 463 environment, such as lost packets, jitter, and out of sequence 464 packets, it that reports conditions of session periodically may have 465 difficulty to guarantee quality-of-service immediately. Mobile 466 environments with many participants and low bandwidth may cause the 467 long interval of RTCP transmission (e.g., five, six seconds or more). 468 Although there is more immediate RTCP feedback (defined in 'Extended 469 RTP profile for RTCP-based Feedback'), RTCP feedback message is heavy 470 to send LPCI. As RTCP feedback message is added the end of normal 471 RTCP packet, it may send unnecessary information in addition to the 472 LPCI. Moreover, RTCP feedback message is hard to respond immediately 473 when the receiver is in the large group. The previously discussed 474 issues are more a problem of RTP itself with a large receiver group 475 than a LPCI specific issue. Therefore, RTP and RTCP might not be 476 appropriate for the LPCI delivery without resolving above problems 477 first, late and inefficient Link and Path Characteristic Information 478 delivery. 480 3.10. SCTP 482 SCTP [RFC2960] is a general-purpose transport layer protocol. SCTP 483 provides features such as multi-streaming and multi-homing that may 484 be helpful in mobility environment. 486 SCTP's current multi-homing allows two end-points to set up an 487 association with multiple IP address for each endpoint. 488 Retransmission of lost packets can be done over the secondary path. 489 Mobile SCTP is able to provide a solution for limited mobility 490 scenarios as well. A multi-access user would be able to roam between 491 heterogeneous access networks without breaking any existing 492 connections. A new connection for the same session can be 493 initialized with separate parameters (congestion window size, MTU 494 ,etc.) 496 As SCTP originally does not provide QoS support, extensions may be 497 needed for expedited LPCI delivery. It should be able to implement 498 LPCI delivery by extending ASCONF chunk message for dynamic address 499 configuration or by making suggestion of new chunk. SCTP is not 500 currently in wide use. 502 4. Table of results 504 Results are presented in the following tables: 506 +-----------+-----+-----+-----+-----+---------+---------+-----+ 507 | Protocol | R1 | R2 | R3 | R4 | R5 | R6 | R7 | 508 +-----------+-----+-----+-----+-----+---------+---------+-----+ 509 | IP | N/A | N/A | Yes | Yes | Var [1] | yes | N/A | 510 | SIP | N/A | N/A | Yes | Yes | Yes | N/A | N/A | 511 | Mobile IP | Yes | Yes | Yes | Yes | Var [7] | Yes [5] | Yes | 512 | CTP | Yes | Yes | Yes | Yes | Var [7] | N/A | N/A | 513 | HIP | Yes | Yes | Yes | Yes | Var [7] | Yes | Yes | 514 | NSIS | Yes | Yes | Yes | Yes | Var[10] | Yes | Yes | 515 | TCP | N/A | N/A | Yes | Yes | Yes | No | Yes | 516 | DCCP | Yes | Yes | Yes | Yes | Yes | Yes | Yes | 517 | RTP/RTCP | N/A | N/A | Yes | Yes | Var [7] | Yes | Yes | 518 | SCTP | Yes | Yes | Yes | Yes | Yes | Yes | Yes | 519 +-----------+-----+-----+-----+-----+---------+---------+-----+ 521 Table 1 523 +-----------+-----+-----+-----+---------+----------+---------+-----+ 524 | Protocol | R8 | R9 | R10 | R11 | R12 | R13 | R14 | 525 +-----------+-----+-----+-----+---------+----------+---------+-----+ 526 | IP | Yes | Yes | Yes | See [2] | N/A | N/A | N/A | 527 | SIP | Yes | Yes | Yes | Yes [3] | Yes [4] | N/A | N/A | 528 | Mobile IP | N/A | Yes | Yes | Yes | Yes | Yes [6] | Yes | 529 | CTP | N/A | Yes | Yes | Yes | Yes | Yes | Yes | 530 | HIP | N/A | Yes | Yes | Yes | Yes(RVS) | Yes | Yes | 531 | NSIS | Yes | Yes | Yes | Yes | Yes | Yes[11] | Yes | 532 | TCP | Yes | Yes | Yes | Yes | No | Yes | Yes | 533 | DCCP | Yes | Yes | Yes | Var [9] | No | No QoS | Yes | 534 | RTP/RTCP | Yes | Yes | Yes | Yes | No [4] | No [8] | Yes | 535 | SCTP | Yes | Yes | Yes | Var [9] | No | No QoS | Yes | 536 +-----------+-----+-----+-----+---------+----------+---------+-----+ 538 Table 2 540 [1] Load depends of implementation option handling. Options have to 541 be examined at every node on the path, except in the case of IPv6 542 Destination Options. 544 [2] NAT's and firewalls generally handle traversal based on 4-tuple 545 of IP addresses and source and destination ports. Also, IPv4 headers 546 may be removed at the intermediate nodes due to lack of 547 classification between end-to-end and hop-by-hop options. 549 [3] SIP traverses through firewalls, but the session that will be set 550 up as a follow-up requires explicit support from the firewall (SIP 551 ALG) or other mechanisms, such as STUN. 553 [4] Delegation via SIP proxies or other mechanisms possible. 555 [5] MIP supports multiple care-of-addresses. 557 [6] Preregistering new care-of-address before deregistering the next 558 allows for seamless handovers. The new care-of-address registration 559 can contain new LPCI values. 561 [7] Explicit messages for ONLY the LPCI data increases signaling 562 load; If LPCI data can be bundled with other (necessary) signaling, 563 load increase is minimal. 565 [8] RTCP message sending delay may grow too large for the information 566 to lose it's significance. Using explicit notifications contradicts 567 R5. 569 [9] Protocol is relatively new, so support in firewalls and NAT 570 equipment is still emerging and not widely available. 572 [10] NSIS as an out-of-band mechanism is naturally more heavy-weight 573 than an in-band mechanism. The total amount of overhead depends, 574 however, on a number of factors. Details can be determined from 575 [nsis-performance-paper]. 577 [11] NSIS needs to be triggered at the new point of attachment while 578 the mobile node is still at the old point of attachment. This is 579 possible in a mobility environment but introduces complexity. 581 5. Conclusions 583 5.1. Results of the Analysis 585 The results of the analysis are that most of the protocols can 586 technically transport the LPCI attributes; i.e. they have a freely- 587 definable option-field or similar structure. However, other 588 constraints may impact feasibility of individual protocols. 590 The primary concern is that the LCI information should not cause too 591 much additional signaling load to the network, and the information 592 should still be of value upon reaching destination. Most transport 593 protocols implement some sort of congestion and flow control, which 594 will cause delay in sending LPCI information 'bundled' with normal 595 flow of information. On the other hand, explicit notification 596 mechanisms will increase load significantly. For example, a single 597 option field in a TCP acknowledgement packet increases the load with 598 a few bytes; but an explicit notification in a separate IP packet 599 (such as the RTP notification mechanism) will require an entire 600 additional packet to be constructed and sent. 602 5.2. Recommendations for the Information Delivery 604 The most problematic situation is a break-before-make handover from a 605 high-speed link to low-speed link. If high bandwidth is available, 606 the additional load caused by explicit notifications are not such a 607 significant issue; even in a make-before-break situation (predictive 608 handover) most of the additional load can be sent on the high-speed 609 link before the handover occurs. 611 After such a handover, the following recommendations can be made: 613 o Use a delegation mechanism, if possible, such as Mobile IP Home 614 agent to make the notifications to peer nodes, to avoid extra load 615 on the final link. 616 o If delegation is not possible, include the LCI data inside 617 standard session packets, such as TCP acknowledgements (packets 618 that would be sent regardless) or Mobile IP path optimization 619 binding update. 620 o Have peers reuse the information; If having multiple sessions with 621 a single host, send the LCI information only once and have it 622 concern all the sessions. 624 The LPCI delivery solution SHOULD be a generic container that can be 625 transferred over any transport protocol. Individual transport 626 protocols MAY use protocol-specific derivations for eg. data 627 compression, but such specifics are beyond the scope of this 628 document. 630 6. IANA Considerations 632 This document does not require actions by IANA. 634 7. Security Considerations 636 Security requirements for the delivery of LPCI have been mentioned in 637 [I-D.korhonen-mobopts-link-characteristics-ps]. This document lists 638 a number of candidate protocols whereby each protocol offers 639 different security properties. A security analysis has to be 640 provided for each protocol. 642 8. Acknowledgments 644 Special thanks to Yunju Choe (contributor of RTP section), Jeongrok 645 Jang (contributor of DCCP section) and Minho Lee (contributor of SCTP 646 section) for their valuable contributions. 648 9. References 650 9.1. Normative References 652 [I-D.korhonen-mobopts-link-characteristics-ps] 653 Korhonen, J., "Link Characteristic Information for IP 654 Mobility Problem Statement", 655 draft-korhonen-mobopts-link-characteristics-ps-01 (work in 656 progress), June 2006. 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, March 1997. 661 9.2. Informative References 663 [I-D.ietf-hip-mm] 664 Nikander, P., "End-Host Mobility and Multihoming with the 665 Host Identity Protocol", draft-ietf-hip-mm-04 (work in 666 progress), June 2006. 668 [I-D.ietf-nsis-applicability-mobility-signaling] 669 Lee, S., "Applicability Statement of NSIS Protocols in 670 Mobile Environments", 671 draft-ietf-nsis-applicability-mobility-signaling-05 (work 672 in progress), June 2006. 674 [I-D.ietf-nsis-nslp-natfw] 675 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 676 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in 677 progress), June 2006. 679 [I-D.ietf-nsis-ntlp] 680 Schulzrinne, H. and R. Hancock, "GIST: General Internet 681 Signaling Transport", draft-ietf-nsis-ntlp-11 (work in 682 progress), August 2006. 684 [I-D.ietf-nsis-qos-nslp] 685 Manner, J., "NSLP for Quality-of-Service Signaling", 686 draft-ietf-nsis-qos-nslp-11 (work in progress), June 2006. 688 [I-D.kohler-dccp-mobility] 689 Kohler, E., "Generalized Connections in the Datagram 690 Congestion Control Protocol", 691 draft-kohler-dccp-mobility-02 (work in progress), 692 June 2006. 694 [MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring 695 Interactions Between Transport Protocols and Middleboxes, 696 in Internet Measurement Conference 2004", August 2004. 698 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 699 September 1981. 701 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 702 RFC 793, September 1981. 704 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 705 Protocol", RFC 2327, April 1998. 707 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 708 (IPv6) Specification", RFC 2460, December 1998. 710 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 711 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 712 Zhang, L., and V. Paxson, "Stream Control Transmission 713 Protocol", RFC 2960, October 2000. 715 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 716 A., Peterson, J., Sparks, R., Handley, M., and E. 717 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 718 June 2002. 720 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 721 August 2002. 723 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 724 Jacobson, "RTP: A Transport Protocol for Real-Time 725 Applications", STD 64, RFC 3550, July 2003. 727 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 728 in IPv6", RFC 3775, June 2004. 730 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 731 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 733 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 734 Bosch, "Next Steps in Signaling (NSIS): Framework", 735 RFC 4080, June 2005. 737 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 738 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 740 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 741 (HIP) Architecture", RFC 4423, May 2006. 743 [nsis-performance-paper] 744 Fu, X., Hogrefe, D., Schulzrinne, H., Tschofenig, H., and 745 C. Dickmann, "Overhead and Performance Study of the 746 General Internet Signaling Transport (GIST) Protocol, in 747 IEEE INFOCOM 2006, Bacelona, Spain, IEEE", April 2006. 749 Authors' Addresses 751 Jouni Korhonen 752 TeliaSonera Corporation. 753 P.O.Box 970 754 FIN-00051 Sonera 755 FINLAND 757 Phone: +358 40 534 4455 758 Email: jouni.korhonen@teliasonera.com 760 Antti Makela 761 TeliaSonera Corporation. 762 P.O.Box 777 763 FIN-33101 Tampere 764 FINLAND 766 Phone: +358 40 824 4170 767 Email: antti.makela@teliasonera.com 769 Soohong Daniel Park 770 Mobile Platform Laboratory, SAMSUNG Electronics. 771 416 Maetan-3dong, Yeongtong-gu 772 Suwon, Gyeonggi-do 443-742 773 KOREA 775 Phone: +82 31 200 4508 776 Email: soohong.park@samsung.com 777 Hannes Tschofenig 778 Siemens 779 Otto-Hahn-Ring 6 780 Munich, Bavaria 81739 781 Germany 783 Email: Hannes.Tschofenig@siemens.com 784 URI: http://www.tschofenig.com 786 Full Copyright Statement 788 Copyright (C) The Internet Society (2006). 790 This document is subject to the rights, licenses and restrictions 791 contained in BCP 78, and except as set forth therein, the authors 792 retain all their rights. 794 This document and the information contained herein are provided on an 795 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 796 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 797 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 798 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 799 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 800 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 802 Intellectual Property 804 The IETF takes no position regarding the validity or scope of any 805 Intellectual Property Rights or other rights that might be claimed to 806 pertain to the implementation or use of the technology described in 807 this document or the extent to which any license under such rights 808 might or might not be available; nor does it represent that it has 809 made any independent effort to identify any such rights. Information 810 on the procedures with respect to rights in RFC documents can be 811 found in BCP 78 and BCP 79. 813 Copies of IPR disclosures made to the IETF Secretariat and any 814 assurances of licenses to be made available, or the result of an 815 attempt made to obtain a general license or permission for the use of 816 such proprietary rights by implementers or users of this 817 specification can be obtained from the IETF on-line IPR repository at 818 http://www.ietf.org/ipr. 820 The IETF invites any interested party to bring to its attention any 821 copyrights, patents or patent applications, or other proprietary 822 rights that may cover technology that may be required to implement 823 this standard. Please address the information to the IETF at 824 ietf-ipr@ietf.org. 826 Acknowledgment 828 Funding for the RFC Editor function is provided by the IETF 829 Administrative Support Activity (IASA).