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