idnits 2.17.1 draft-ietf-nsis-ntlp-sctp-02.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 'Intended status' indicated for this document; assuming Proposed Standard 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 18, 2007) is 6004 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-14 ** 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 (~~), 4 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 Expires: May 21, 2008 University of Goettingen 5 J. Crowcroft 6 University of Cambridge 7 November 18, 2007 9 General Internet Signaling Transport (GIST) over SCTP 10 draft-ietf-nsis-ntlp-sctp-02.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 May 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 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 keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL", in this document are to be interpreted as described in 125 BCP 14, RFC 2119 [4]. Other terminologies and abbreviations used in 126 this document are taken from related specifications (e.g., [1] and 128 [2]) as follows: 129 o SCTP - Stream Control Transmission Protocol 130 o PR-SCTP - SCTP Partial Reliability Extension 131 o MRM - Message Routing Method 132 o MRI - Message Routing Information 133 o MRS - Message Routing State 134 o MA - A GIST Messaging Association is a single connection between 135 two explicitly identified GIST adjacent peers on the data path. A 136 messaging association may use a specific transport protocol and 137 known ports. If security protection is required, it may use a 138 specific network layer security association, or use a transport 139 layer security association internally. A messaging association is 140 bidirectional; signaling messages can be sent over it in either 141 direction, and can refer to flows of either direction. 142 o SCTP Association - A protocol relationship between SCTP endpoints, 143 composed of the two SCTP endpoints and protocol state information. 144 An association can be uniquely identified by the transport 145 addresses used by the endpoints in the association. Two SCTP 146 endpoints MUST NOT have more than one SCTP association between 147 them at any given time. 148 o Stream - A sequence of user messages that are to be delivered to 149 the upper-layer protocol in order with respect to other messages 150 within the same stream. 152 3. GIST Over SCTP 154 3.1. Message Association Setup 156 3.1.1. Overview 158 The basic GIST protocol specification defines two possible protocols 159 to be used in Messaging Associations, namely Forwards-TCP and TLS. 160 This document adds Forwards-SCTP as another possible protocol. In 161 Forwards-SCTP, analog to Forwards-TCP, connections between peers are 162 opened in the forwards direction, from the querying node, towards the 163 responder. 165 A new MA-Protocol-ID type, "Forwards-SCTP", is defined in this 166 document for using SCTP as GIST transport protocol. A formal 167 definition of Forwards-SCTP is given in the following section. 169 3.1.2. Protocol-Definition: Forwards-SCTP 171 This MA-Protocol-ID denotes a basic use of SCTP between peers. 172 Support for this protocol is OPTIONAL. If this protocol is offered, 173 MA-protocol-options data MUST also be carried in the SCD object. The 174 MA-protocol-options field formats are: 176 o in a Query: no information apart from the field header. 177 o in a Response: 2 byte port number at which the connection will be 178 accepted, followed by 2 pad bytes. 180 The connection is opened in the forwards direction, from the querying 181 node towards the responder. The querying node MAY use any source 182 address and source port. The destination information MUST be derived 183 from information in the Response: the address from the interface- 184 address from the Network-Layer-Information object and the port from 185 the SCD object as described above. 187 Associations using Forwards-SCTP can carry messages with the transfer 188 attribute Reliable=True. If an error occurs on the SCTP connection 189 such as a reset, as can be detected for example by a socket exception 190 condition, GIST MUST report this to NSLPs as discussed in Section 191 4.1.2 of [1]. 193 3.2. Effect on GIST State Maintenance 195 This document defines the use of SCTP as a transport protocol for 196 GIST Messaging Associations. As SCTP provides additional 197 functionality over TCP, this section dicusses the implications of 198 using GIST over SCTP on GIST State Maintenance. 200 While SCTP defines uni-directional streams, for the purpose of this 201 document, the concept of a bi-direction stream is used. 202 Implementations MUST establish downstream and upstream (uni- 203 directional) SCTP streams always together and use the same stream 204 identifier in both directions. Thus, the two uni-directional streams 205 (in opposite directions) form a bi-directional stream. 207 Due to the multi-streaming support of SCTP, it is possible to use 208 different SCTP streams for different resources (e.g., different NSLP 209 sessions), rather than maintaining all messages along the same 210 transport connection/association in a correlated fashion as TCP 211 (which imposes strict (re)ordering and reliability per transport 212 level). However, there are limitations to the use of multi- 213 streaming. All GIST messages for a particular session MUST be sent 214 over the same SCTP stream to assure the NSLP assumption of in-order 215 delivery. Multiple sessions MAY share the same SCTP stream based on 216 local policy. 218 The GIST concept of Messaging Association re-use is not affected by 219 this document or the use of SCTP. All rules defined in the GIST 220 specification remain valid in the context of GIST over SCTP. 222 3.3. PR-SCTP Support 224 A variant of SCTP, PR-SCTP [3] provides a "timed reliability" 225 service. It allows the user to specify, on a per message basis, the 226 rules governing how persistent the transport service should be in 227 attempting to send the message to the receiver. Because of the chunk 228 bundling function of SCTP, reliable and partial reliable messages can 229 be multiplexed over a single PR-SCTP association. Therefore, a GIST 230 over SCTP implementation SHOULD attempt to establish a PR-SCTP 231 association instead of a standard SCTP association, if available, to 232 support more flexible transport features for potential needs of 233 different NSLPs. 235 3.4. API between GIST and NSLP 237 GIST specification defines an abstract API between GIST and NSLPs. 238 While this document does not change the API itself, the semantics of 239 some parameters have slightly different interpretation in the context 240 of SCTP. This section only lists those primitives and parameters, 241 that need special consideration when used in the context of SCTP. 242 The relevant primitives are repeatet from [1] to improve readability, 243 but [1] remains authoritative. 245 3.4.1. SendMessage 247 The SendMessage primitive is used by the NSLP to initiate sending of 248 messages. 250 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 251 NSLP-Id, Session-ID, MRI, 252 SSI-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC ) 254 The following parameter has changed semantics: 256 Timeout: According to [1] this parameter represents the "length of 257 time GIST should attempt to send this message before indicating an 258 error". When used with SCTP, this parameter is also used as the 259 timeout for the "timed reliability" service of PR-SCTP. 261 3.4.2. NetworkNotification 263 The NetworkNotification primitive is passed from GIST to an NSLP. It 264 indicates that a network event of possible interest to the NSLP 265 occurred. 267 NetworkNotification ( MRI, Network-Notification-Type ) 268 If SCTP detects a failure of the primary path, GIST should indicate 269 this event to the NSLP by calling the NetworkNotification primitive 270 with Network-Notification-Type "Routing Status Change". This 271 notification should be done even if SCTP was able to remain an open 272 connection to the peer due to its multi-homing capabilities. 274 4. Bit-Level Formats 276 4.1. MA-Protocol-Options 278 This section provides the bit-level format for the MA-protocol- 279 options field that is used for SCTP protocol in the Stack- 280 Configuration-Data object of GIST. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 : SCTP port number | Reserved : 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 SCTP port number = Port number at which the responder will accept 289 SCTP connections 291 The SCTP port number is only supplied if sent by the responder. 293 5. Application of GIST over SCTP 295 5.1. Multi-homing support of SCTP 297 In general, the multi-homing support of SCTP can be used to improve 298 fault-tolerance in case of a path- or link-failure. Thus, GIST over 299 SCTP would be able to deliver NSLP messages between peers even if the 300 primary path is not working anymore. However, for the Message 301 Routing Methods (MRMs) defined in the basic GIST specification such a 302 feature is only of limited use. The default MRM is path-coupled, 303 which means, that if the primary path is failing for the SCTP 304 association, it most likely is also for the IP traffic that is 305 signaled for. Thus, GIST would need to perform a refresh anyway to 306 cope with the route change. Nevertheless, the use of the multi- 307 homing support of SCTP provides GIST and the NSLP with another source 308 to detect route changes. Furthermore, for the time between detection 309 of the route change and recovering from it, the alternative path 310 offered by SCTP can be used by the NSLP to make the transition more 311 smoothly. Finally, future MRMs might have different properties and 312 therefore benefit from multi-homing more broadly. 314 5.2. Streaming support in SCTP 316 Streaming support in SCTP is advantageous for GIST. It allows better 317 parallel processing, in particular by avoiding head of line blocking 318 issue in TCP. Since a same GIST MA may be reused by multiple 319 sessions, using TCP as transport GIST signaling messages belonging to 320 different sessions may be blocked if another message is dropped. In 321 the case of SCTP, this can be avoided as different sessions having 322 different requirements can belong to different streams, thus a 323 message loss or reordering in a stream will only affect the delivery 324 of messages within that particular stream, and not any other streams. 326 6. Security Considerations 328 The security considerations of both [1] and [2] apply. For securing 329 GIST over SCTP channel, it is recommended to use DTLS [7], to take 330 the advantage of all the features provided by SCTP and its 331 extensions. DTLS over SCTP is currently being specified in [8]. The 332 usage of DTLS for GIST is similar to TLS for GIST as specified in 333 [1], and a MA-protocol-ID for DTLS is yet to be defined in another 334 document. 336 7. IANA Considerations 338 A new MA-Protocol-ID (Forwards-SCTP) needs to be assigned, with a 339 recommended value of 3. 341 8. Acknowledgments 343 The authors would like to thank John Loughney, Robert Hancock, Andrew 344 McDonald, Fang-Chun Kuo and Jan Demter for their 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-14 (work in 352 progress), July 2007. 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 for Informatics 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 for Informatics 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 (2007). 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).