idnits 2.17.1 draft-ietf-nsis-ntlp-sctp-05.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 445. 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 IETF Trust 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 26, 2008) is 5659 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-16 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') ** Obsolete normative reference: RFC 4960 (ref. '2') (Obsoleted by RFC 9260) == Outdated reference: A later version (-06) exists of draft-ietf-tsvwg-dtls-for-sctp-00 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '6') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. '8') (Obsoleted by RFC 6347) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft C. Dickmann 4 Intended status: Standards Track University of Goettingen 5 Expires: April 29, 2009 J. Crowcroft 6 University of Cambridge 7 October 26, 2008 9 General Internet Signaling Transport (GIST) over SCTP 10 draft-ietf-nsis-ntlp-sctp-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2009. 37 Abstract 39 The General Internet Signaling Transport (GIST) protocol currently 40 uses TCP or TLS over TCP for connection mode operation. This 41 document describes the usage of GIST over the Stream Control 42 Transmission Protocol (SCTP). The use of SCTP can take advantage of 43 features provided by SCTP, namely streaming-based transport, support 44 of multiple streams to avoid head of line blocking, the support of 45 multi-homing to provide network level fault tolerance, as well as 46 partial reliability extension for partially reliable data 47 transmission. Additionally, the support for datagram TLS is also 48 discussed. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 54 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Message Association Setup . . . . . . . . . . . . . . . . 4 56 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 4 58 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 59 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6 60 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6 61 3.4.1. SendMessage . . . . . . . . . . . . . . . . . . . . . 6 62 3.4.2. NetworkNotification . . . . . . . . . . . . . . . . . 6 63 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7 65 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7 66 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7 67 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 Intellectual Property and Copyright Statements . . . . . . . . . . 11 77 1. Introduction 79 This document describes the usage of the General Internet Signaling 80 Transport (GIST) protocol [1] over the Stream Control Transmission 81 Protocol (SCTP) [2]. 83 GIST, in its initial specification for connection mode operation, 84 runs on top of a byte-stream oriented transport protocol providing a 85 reliable, in-sequence delivery, i.e., using the Transmission Control 86 Protocol (TCP) [6] for signaling message transport. However, some 87 NSLP context information has a definite lifetime, therefore, the GIST 88 transport protocol could benefit from flexible retransmission, so 89 stale NSLP messages that are held up by congestion can be dropped. 90 Together with the head-of-line blocking issue and other issues with 91 TCP, these considerations argue that implementations of GIST should 92 support the Stream Control Transport Protocol (SCTP)[2] as an 93 optional transport protocol for GIST, especially if deployment over 94 the public Internet is contemplated. Like TCP, SCTP supports 95 reliability, congestion control and fragmentation. Unlike TCP, SCTP 96 provides a number of functions that are desirable for signaling 97 transport, such as multiple streams and multiple IP addresses for 98 path failure recovery. In addition, its Partial Reliability 99 extension (PR-SCTP) [3] supports partial retransmission based on a 100 programmable retransmission timer. Furthermore, Datagram Transport 101 Layer Security (DTLS) over SCTP [4] provides a viable solution for 102 securing SCTP. 104 This document defines the use of SCTP as a transport protocol for 105 GIST Messaging Associations and discusses the implications on GIST 106 State Maintenance and API between GIST and NSLPs. Furturemore, this 107 document shows how GIST SHOULD be used to provide the additional 108 features offered by SCTP to deliver the GIST C-mode messages (which 109 can in turn carry NSIS Signaling Layer Protocol (NSLP) [7] messages 110 as payload). More specifically: 111 o How to use the multiple streams feature of SCTP. 112 o How to use the PR-SCTP extention of SCTP. 113 o How to take advantage of the multi-homing support of SCTP. 115 The method described in this document does not require any changes of 116 GIST or SCTP. However, SCTP implementations MUST support the 117 optional feature of fragmentation of SCTP user messages. 119 2. Terminology and Abbreviations 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [5]. Other 124 terminologies and abbreviations used in this document are taken from 125 related specifications (e.g., [1] and [2]) as follows: 126 o SCTP - Stream Control Transmission Protocol 127 o PR-SCTP - SCTP Partial Reliability Extension 128 o MRM - Message Routing Method 129 o MRI - Message Routing Information 130 o MRS - Message Routing State 131 o MA - A GIST Messaging Association is a single connection between 132 two explicitly identified GIST adjacent peers on the data path. A 133 messaging association may use a specific transport protocol and 134 known ports. If security protection is required, it may use a 135 specific network layer security association, or use a transport 136 layer security association internally. A messaging association is 137 bidirectional; signaling messages can be sent over it in either 138 direction, and can refer to flows of either direction. 139 o SCTP Association - A protocol relationship between SCTP endpoints, 140 composed of the two SCTP endpoints and protocol state information. 141 An association can be uniquely identified by the transport 142 addresses used by the endpoints in the association. Two SCTP 143 endpoints MUST NOT have more than one SCTP association between 144 them at any given time. 145 o Stream - A sequence of user messages that are to be delivered to 146 the upper-layer protocol in order with respect to other messages 147 within the same stream. 149 3. GIST Over SCTP 151 3.1. Message Association Setup 153 3.1.1. Overview 155 The basic GIST protocol specification defines two possible protocols 156 to be used in Messaging Associations, namely Forwards-TCP and TLS. 157 This document adds Forwards-SCTP as another possible protocol. In 158 Forwards-SCTP, analog to Forwards-TCP, connections between peers are 159 opened in the forwards direction, from the querying node, towards the 160 responder. 162 A new MA-Protocol-ID type, "Forwards-SCTP", is defined in this 163 document for using SCTP as GIST transport protocol. A formal 164 definition of Forwards-SCTP is given in the following section. 166 3.1.2. Protocol-Definition: Forwards-SCTP 168 This MA-Protocol-ID denotes a basic use of SCTP between peers. 169 Support for this protocol is OPTIONAL. If this protocol is offered, 170 MA-protocol-options data MUST also be carried in the SCD object. The 171 MA-protocol-options field formats are: 172 o in a Query: no information apart from the field header. 173 o in a Response: 2 byte port number at which the connection will be 174 accepted, followed by 2 pad bytes. 176 The connection is opened in the forwards direction, from the querying 177 node towards the responder. The querying node MAY use any source 178 address and source port. The destination information MUST be derived 179 from information in the Response: the address from the interface- 180 address from the Network-Layer-Information object and the port from 181 the SCD object as described above. 183 Associations using Forwards-SCTP can carry messages with the transfer 184 attribute Reliable=True. If an error occurs on the SCTP connection 185 such as a reset, as can be detected for example by a socket exception 186 condition, GIST MUST report this to NSLPs as discussed in Section 187 4.1.2 of [1]. 189 3.2. Effect on GIST State Maintenance 191 This document defines the use of SCTP as a transport protocol for 192 GIST Messaging Associations. As SCTP provides additional 193 functionality over TCP, this section dicusses the implications of 194 using GIST over SCTP on GIST State Maintenance. 196 While SCTP defines uni-directional streams, for the purpose of this 197 document, the concept of a bi-direction stream is used. 198 Implementations MUST establish downstream and upstream (uni- 199 directional) SCTP streams always together and use the same stream 200 identifier in both directions. Thus, the two uni-directional streams 201 (in opposite directions) form a bi-directional stream. 203 Due to the multi-streaming support of SCTP, it is possible to use 204 different SCTP streams for different resources (e.g., different NSLP 205 sessions), rather than maintaining all messages along the same 206 transport connection/association in a correlated fashion as TCP 207 (which imposes strict (re)ordering and reliability per transport 208 level). However, there are limitations to the use of multi- 209 streaming. All GIST messages for a particular session MUST be sent 210 over the same SCTP stream to assure the NSLP assumption of in-order 211 delivery. Multiple sessions MAY share the same SCTP stream based on 212 local policy. 214 The GIST concept of Messaging Association re-use is not affected by 215 this document or the use of SCTP. All rules defined in the GIST 216 specification remain valid in the context of GIST over SCTP. 218 3.3. PR-SCTP Support 220 A variant of SCTP, PR-SCTP [3] provides a "timed reliability" 221 service. It allows the user to specify, on a per message basis, the 222 rules governing how persistent the transport service should be in 223 attempting to send the message to the receiver. Because of the chunk 224 bundling function of SCTP, reliable and partial reliable messages can 225 be multiplexed over a single PR-SCTP association. Therefore, a GIST 226 over SCTP implementation SHOULD attempt to establish a PR-SCTP 227 association instead of a standard SCTP association, if available, to 228 support more flexible transport features for potential needs of 229 different NSLPs. 231 3.4. API between GIST and NSLP 233 GIST specification defines an abstract API between GIST and NSLPs. 234 While this document does not change the API itself, the semantics of 235 some parameters have slightly different interpretation in the context 236 of SCTP. This section only lists those primitives and parameters, 237 that need special consideration when used in the context of SCTP. 238 The relevant primitives are repeatet from [1] to improve readability, 239 but [1] remains authoritative. 241 3.4.1. SendMessage 243 The SendMessage primitive is used by the NSLP to initiate sending of 244 messages. 246 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 247 NSLP-Id, Session-ID, MRI, 248 SSI-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC ) 250 The following parameter has changed semantics: 252 Timeout: According to [1] this parameter represents the "length of 253 time GIST should attempt to send this message before indicating an 254 error". When used with SCTP, this parameter is also used as the 255 timeout for the "timed reliability" service of PR-SCTP. 257 3.4.2. NetworkNotification 259 The NetworkNotification primitive is passed from GIST to an NSLP. It 260 indicates that a network event of possible interest to the NSLP 261 occurred. 263 NetworkNotification ( MRI, Network-Notification-Type ) 264 If SCTP detects a failure of the primary path, GIST SHOULD indicate 265 this event to the NSLP by calling the NetworkNotification primitive 266 with Network-Notification-Type "Routing Status Change". This 267 notification should be done even if SCTP was able to remain an open 268 connection to the peer due to its multi-homing capabilities. 270 4. Bit-Level Formats 272 4.1. MA-Protocol-Options 274 This section provides the bit-level format for the MA-protocol- 275 options field that is used for SCTP protocol in the Stack- 276 Configuration-Data object of GIST. 278 0 1 2 3 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 : SCTP port number | Reserved : 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 SCTP port number = Port number at which the responder will accept 285 SCTP connections 287 The SCTP port number is only supplied if sent by the responder. 289 5. Application of GIST over SCTP 291 5.1. Multi-homing support of SCTP 293 In general, the multi-homing support of SCTP can be used to improve 294 fault-tolerance in case of a path- or link-failure. Thus, GIST over 295 SCTP would be able to deliver NSLP messages between peers even if the 296 primary path is not working anymore. However, for the Message 297 Routing Methods (MRMs) defined in the basic GIST specification such a 298 feature is only of limited use. The default MRM is path-coupled, 299 which means, that if the primary path is failing for the SCTP 300 association, it most likely is also for the IP traffic that is 301 signaled for. Thus, GIST would need to perform a refresh anyway to 302 cope with the route change. Nevertheless, the use of the multi- 303 homing support of SCTP provides GIST and the NSLP with another source 304 to detect route changes. Furthermore, for the time between detection 305 of the route change and recovering from it, the alternative path 306 offered by SCTP can be used by the NSLP to make the transition more 307 smoothly. Finally, future MRMs might have different properties and 308 therefore benefit from multi-homing more broadly. 310 5.2. Streaming support in SCTP 312 Streaming support in SCTP is advantageous for GIST. It allows better 313 parallel processing, in particular by avoiding head of line blocking 314 issue in TCP. Since a same GIST MA may be reused by multiple 315 sessions, using TCP as transport GIST signaling messages belonging to 316 different sessions may be blocked if another message is dropped. In 317 the case of SCTP, this can be avoided as different sessions having 318 different requirements can belong to different streams, thus a 319 message loss or reordering in a stream will only affect the delivery 320 of messages within that particular stream, and not any other streams. 322 6. Security Considerations 324 The security considerations of both [1] and [2] apply. For securing 325 GIST over SCTP channel, it is recommended to use DTLS [8], to take 326 the advantage of all the features provided by SCTP and its 327 extensions. DTLS over SCTP is specified in [4]. The usage of DTLS 328 for GIST over SCTP is similar to TLS for GIST as specified in [1], 329 where a stack-proposal containing both MA-Protocol-IDs for SCTP and 330 DTLS during the GIST handshake phase. 332 7. IANA Considerations 334 Two new MA-Protocol-IDs (Forwards-SCTP and Fowards-DTLS) need to be 335 assigned, with a recommended values of 3 and 4. 337 8. Acknowledgments 339 The authors would like to thank John Loughney, Robert Hancock, Andrew 340 McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, and Michael 341 Tuexen for their helpful suggestions. 343 9. References 345 9.1. Normative References 347 [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet 348 Signalling Transport", draft-ietf-nsis-ntlp-16 (work in 349 progress), July 2008. 351 [2] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 352 September 2007. 354 [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 355 "Stream Control Transmission Protocol (SCTP) Partial Reliability 356 Extension", RFC 3758, May 2004. 358 [4] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport 359 Layer Security for Stream Control Transmission Protocol", 360 draft-ietf-tsvwg-dtls-for-sctp-00 (work in progress), 361 October 2008. 363 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 364 Levels", BCP 14, RFC 2119, March 1997. 366 9.2. Informative References 368 [6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 369 September 1981. 371 [7] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 372 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 373 June 2005. 375 [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 376 Security", RFC 4347, April 2006. 378 Authors' Addresses 380 Xiaoming Fu 381 University of Goettingen 382 Institute of Computer Science 383 Goldschmidtstr. 7 384 Goettingen 37077 385 Germany 387 Email: fu@cs.uni-goettingen.de 389 Christian Dickmann 390 University of Goettingen 391 Institute of Computer Science 392 Goldschmidtstr. 7 393 Goettingen 37077 394 Germany 396 Email: mail@christian-dickmann.de 397 Jon Crowcroft 398 University of Cambridge 399 Computer Laboratory 400 William Gates Building 401 15 JJ Thomson Avenue 402 Cambridge CB3 0FD 403 UK 405 Email: jon.crowcroft@cl.cam.ac.uk 407 Full Copyright Statement 409 Copyright (C) The IETF Trust (2008). 411 This document is subject to the rights, licenses and restrictions 412 contained in BCP 78, and except as set forth therein, the authors 413 retain all their rights. 415 This document and the information contained herein are provided on an 416 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 417 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 418 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 419 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 420 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 421 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 423 Intellectual Property 425 The IETF takes no position regarding the validity or scope of any 426 Intellectual Property Rights or other rights that might be claimed to 427 pertain to the implementation or use of the technology described in 428 this document or the extent to which any license under such rights 429 might or might not be available; nor does it represent that it has 430 made any independent effort to identify any such rights. Information 431 on the procedures with respect to rights in RFC documents can be 432 found in BCP 78 and BCP 79. 434 Copies of IPR disclosures made to the IETF Secretariat and any 435 assurances of licenses to be made available, or the result of an 436 attempt made to obtain a general license or permission for the use of 437 such proprietary rights by implementers or users of this 438 specification can be obtained from the IETF on-line IPR repository at 439 http://www.ietf.org/ipr. 441 The IETF invites any interested party to bring to its attention any 442 copyrights, patents or patent applications, or other proprietary 443 rights that may cover technology that may be required to implement 444 this standard. Please address the information to the IETF at 445 ietf-ipr@ietf.org.