idnits 2.17.1 draft-ietf-sigtran-sctp-applicability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 309 has weird spacing: '...ided on diffe...' == Line 400 has weird spacing: '...es/gaps betwe...' == Line 599 has weird spacing: '...rotocol provi...' == Line 661 has weird spacing: '...tecture frame...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '07' on line 681 looks like a reference -- Missing reference section? '09' on line 689 looks like a reference -- Missing reference section? '10' on line 692 looks like a reference -- Missing reference section? '08' on line 684 looks like a reference -- Missing reference section? '06' on line 678 looks like a reference -- Missing reference section? '01' on line 656 looks like a reference -- Missing reference section? '02' on line 661 looks like a reference -- Missing reference section? '03' on line 669 looks like a reference -- Missing reference section? '04' on line 672 looks like a reference -- Missing reference section? '05' on line 675 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Signalling Transport Working Group L. Coene, Siemens 2 Request for Comments: J. Loughney, Nokia 3 I. Rytina, Ericsson 4 L. Ong, Nortel Networks 6 Simple Control Transmission Protocol(SCTP) applicability statement 7 draft-ietf-sigtran-sctp-applicability-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 24 Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html 27 Abstract 29 This document describes the applicability of the Simple Control 30 Transmission Protocol for general usage. A few general application 31 are descibed such as the transport of signalling information(SS7, 32 DSS1/2...) over IP infrastructure. The use and specification of 33 adaptation layers in conjuction with SCTP is described. 35 1 Introduction 37 This document covers subject terminology and makes a overview of 38 the solutions for transporting information over Internet Protocol 40 Draft SCTP applicability statement March 2000 42 infrastructure. The transport medium used is the Simple Control 43 Transmission Protocol(SCTP). However some of the issues may also 44 relate to the transport of information via TCP. 46 SCTP provides the following services to its users: 48 - acknowledged error-free non-duplicated transfer of user data 50 - application-level segmentation to conform to discovered MTU 51 size 53 - sequenced delivery of user datagrams within multiple streams, 54 with an option for order-of-arrival delivery of individual 55 datagrams 57 - optional multiplexing of user datagrams into SCTP datagrams, 58 subject to MTU size restrictions 60 - enhanced reliability through support of multi-homing at either 61 or both ends of the association. 63 - Explicit indication in the message of the application protocol 64 SCTP is carrying. 66 1.1 Terminology 68 The following functions are commonly identified in related work: 70 Portnumber: Indicates on the tranport level which application 71 needs to be reached in the layer above. 73 Transport Address: An IP address and a portnumber forms a tran- 74 sport address which identifies a SCTP association. 76 Protocol Identifier: Indicates the upper layer protocol that is 77 using SCTP for the tranport of its data. 79 Chunk: a unit of information within an SCTP datagram, consist- 80 ing of a chunk header and chunk-specific content. Each chunk can 81 contain user or data information about the particular SCTP 83 Draft SCTP applicability statement March 2000 85 association. 87 2 Simple Control Transmission Protocol -- SCTP 89 2.1 Introduction 91 The Simple Control Transmission Protocol(SCTP) provides a high reli- 92 alable, redundant transport between 2 endpoints. The interface 93 between SCTP and its applications is handled via adaptation layers 94 which provide a intermediation layer so that the upper layer proto- 95 cols of a certain protocol stack architecture do not have to change 96 their interface towards the transport medium and internal functional- 97 ity when they start using SCTP instead of a other transport protocol 99 The following function are provided by SCTP: 101 - Initialization of transport association 103 - Synchronization of association state 105 - Synchronization of sequence numbering 107 - Reliable Data Transfer 109 - Forward and backward sequence numbering 111 - Timers for transmission and acknowledgement 113 - Notification of out-of-sequence - Retransmission of 114 lost messages 116 - Support of multiple control streams 118 - Separate sequence control and delivery of each 119 stream 121 - Congestion control 123 - Window flow control 125 - Congestion avoidance based on on TCP methods, e.g. 126 using 127 retransmission backoff, window reduction, etc. 129 - Detection of session failure by active means, e.g. heart- 130 beat 132 Draft SCTP applicability statement March 2000 134 - Termination of association 136 SCTP does support a number of functions that are not provided by 137 current TCP: 139 - no head-of-line blocking, i.e. multiple streams 141 - multilink failover for added reliability 143 - keep-alive function for active rapid failure detection 145 - message verses byte sequence numbering 147 - tighter timer control (than standard TCP implementations) 149 - greater fan out (than standard TCP implementations) 151 By defining the approriate User adaptation module, a reliable 152 transport mechanism can be provided: 154 - relialable transmission of packets with end-to-end congestion 155 control provided using methods similar to TCP 157 - choice between sequenced and unsequenced, relialable msg 158 delivery 160 - keep-alive msg 162 Within a association between the 2 endpoint, 1 or more stream(s) may 163 be avialable. These streams are visible to the adaptation layers but 164 are invisible to any layer above the adaptation layer. 166 2.2 Issues affecting deployement of SCTP 168 2.2.1 SCTP Multihoming 170 Redundant communication between 2 SCTP endpoints is achieved by using 171 multihoming where the endpoint is able to send/receive over more than 172 one IP address. 174 Under the assumption that every IP address will have a different path 175 towards the remote endpoint, (this is the responsability of the rout- 176 ing protocols(3.2.4) or of manual configuration), if the transport to 177 one of the IP address (= 1 particular path) fails then the traffic 178 can migrate to the other remaining IP address(= other paths). 180 Draft SCTP applicability statement March 2000 182 Multihoming provides redundant communication in SCTP by allowing com- 183 munication between two endpoints to continue in the event of failure 184 along a path between the endpoints. 186 SCTP will always send its traffic to a certain transport address(= 187 destination address + portnumber combination) for as long as the 188 transmission is uninterupted(=primary). The other transport 189 addresses(secondary paths) will act as a backup in case the primary 190 path goes out of service. The changeover between primary are backup 191 will occur without packetloss and is completely transparent to the 192 application. 194 The portnumber is the same for all transport addresses of that 195 specific association. 197 Applications using directly SCTP may choose to control the multihom- 198 ing service themselves. The applications has then to supply the 199 specifc IP address to SCTP for each datagram. This might be done for 200 reasons of loadsharing and loadbalancing across the different paths. 201 This might not be advisable as the througput of any of the paths is 202 not known in advance and constantly changes due to the actions of 203 other associations and transport protocols along that particular 204 path, would require very tight feedback of each of the paths to the 205 loadsharing functions of the user. 207 Applications using adaptation layers to run over SCTP do not have 208 that kind of control. The adaptation layers will have to take care of 209 this. 211 By sending a keepalive message on all the multiple paths that are not 212 used for active transmission of messages accross the association, it 213 is possible for SCTP to detect whether one or more paths have failed. 214 SCTP will not use these failed paths when a changeover is required. 216 The transmission rate of sending keepalive msg should be engineerable 217 and the possible loss of keepalive msg could be used for the monitor- 218 ing and measurements of the concerned paths. 220 2.2.2 Fast retransmit of chunks 222 The retransmission of a msg is basically governed by the retransmis- 223 sion timer. So if no acknowledgement is received after a certain 224 time, then the msg is retransmitted. However there is a faster way 225 for retransmitting which is not dependant on that timer. 227 Every second msg that a node received will be acknowledge to the 229 Draft SCTP applicability statement March 2000 231 remote peer. If gaps occur in the acknowledge msg at the remote side, 232 then the remote side will wait 3 further gap 233 reports(acknowledgements) before it retransmit the msg. This 234 retransmission will happen far sooner than with a timer. Especially 235 if the traffic volume increases in SCTP, those retransmissions of the 236 chunks would happen faster and faster(and hopefully, they would also 237 be faster acknowledged) 239 See also the paragraph on congestion control and avoidance. 241 2.2.3 Use of SCTP in Network Adress Translator(NAT) networks 243 When a NAT is present between two endpoints, the endpoint that is 244 behind the NAT, i.e., one that does not have a publicly available 245 network address, shall take one of the following options: 247 A) Indicate that only one address can be used by including no tran- 248 sport addresses in the INIT message. This will make the endpoint that 249 receives this Initiation message to consider the sender as only hav- 250 ing that one address. This method can be used for a dynamic NAT, but 251 any multi-homing configuration at the endpoint that is behind the NAT 252 will not be visible to its peer, and thus not be taken advantage of. 254 B) Indicate all of its networks in the Initiation by specifying all 255 the actual IP addresses and ports that the NAT will substitute for 256 the endpoint. This method requires that the endpoint behind the NAT 257 must have pre-knowledge of all the IP addresses and ports that the 258 NAT will assign. 260 This requires the adaptation of NAT boxes to go searching in SCTP 261 outgoing INIT and incoming INIT_ACK for the addresses and replace 262 them with the NAT internal address in addition to replace the 263 addresses in the IP header. 265 C) Use RSIP[] where the connection is tunnelled from host till the 266 NAT border and the host layers above IP networklayer have no 267 knowledge of the NAT internal addresses. 269 2.2.4 MTU path discovery 271 SCTP discovers the minimal length of the msg that can be transported 272 through the network to the final destination without having to frag- 273 ment the msg in IP network layer. This avoids using IP fragmenting 274 which if a segemented of a fragmented msg is discarded, only that 275 segment will be transmitted by SCTP (contrasted with segementing in 277 Draft SCTP applicability statement March 2000 279 IP where the whole unsegmented msg will have to be retransmitted and 280 after a longer time) -> fast retransmit of SCTP. See [07]. 282 2.2.5 Use of multiple streams 284 The application can choose on which stream he can send it data. Some 285 application level protocols may standardize some stream number usage 286 convention, which, for instance, allows to send jpeg and gif portions 287 of a page through certain stream while text through others, so as to 288 avoid large graphics from blocking text content. 290 Each stream within a association should be looked upon as a link 291 between two points. If multiple streams are used then the application 292 is dealing with mulitple links towards the destination. Some applica- 293 tion require the use of sequence delivery, which would require for 294 them to select a certain link to send their message on. 296 2.2.6 Congestion control & avoidance 298 Congestion control and/or avoidance is of primordial importance in 299 any connectionless network. Congestion is the result of approaching 300 or exceeding the processing capacity of the link, network , applica- 301 tion and/or transport layers. If the processing capacity is exceeded, 302 then the congestion can be avoided(example taking a other non- 303 congested path towards the destination) or controlled(example : 304 reducing the rate of messages to that destination). 306 The reaction of SCTP to congestion is detailed in the next para- 307 graphs. 309 Congestion can be controlled and/or avoided on different levels: 311 - Transport: congestion control/avoidance within SCTP, TCP(fig 312 2.1.2) 314 - Network : Congestion control/avoidance present in the network 315 layers( example: SCCP, MTP ...) 317 - Link layer: flow control 319 SCTP conforms to the model of end-to-end congestion control(Fig 320 2.2.6.2) while ISUP and SCCP model themselves on a link and network 321 based congestion control/overload mechanism(Fig 2.2.6.3). 323 Draft SCTP applicability statement March 2000 325 | | 326 | Application and/or transport layer | 327 +---------------------------------------------------+ 328 | A 329 | | 330 | +-------------------------------------+ | 331 ---->| |---- 332 | Network layer | 333 ---->| |---- 334 | +-------------------------------------+ | 335 | | 336 | V 337 +---------------------------------------------------+ 338 | | 339 | Link layer | 341 Fig 2.2.6.1 General Congestion model 343 | | 344 |transport layer| Congestion control present based on 345 | SCTP | windows 346 +---------------+ 347 | A 348 V | 349 +---------------+ 350 | | 351 | Network layer | No congestion control present 352 | IP(v4/v6) | in the IP layer 353 +---------------+ 354 | A 355 V | 356 +---------------+ 357 | Ethernet | No congestion control present 358 | Link layer | in the ethernnet link layer 360 Fig 2.2.6.2 End-to-End congestion control 362 Draft SCTP applicability statement March 2000 364 | | 365 |Application layer| Congestion control present for 366 | TC + MAP,IN... | specific applications 367 +-----------------+ - MAP: No congestion control 368 | A - IN: Call gapping 369 V | 370 +-----------------+ 371 | | 372 | Network layer | Congestion control present in the 373 | SCCP & MTP | in MTP and SCCP based on link and 374 +-----------------+ destination status 375 | A 376 V | 377 +-----------------+ 378 | MTP lvl 2 | Congestion control present 379 | Link layer | in the link layer 381 Fig 2.2.6.3 Distributed congestion control 383 By default, SCTP associations do not have a fixed capacity assigned 384 to them unless other QOS mechanisms are employed.Thus congestion 385 within SCTP association can and will be affected by all traffic using 386 the same links including other SCTP, TCP, RTP, UDP... traffic going 387 through the same links of the path followed by the SCTP association. 389 2.2.6.1 Application of Congestion control in SCTP - 3-SACK rule 391 The Selective Acknowledgement(SACK) is one of the cornerstones of 392 SCTP. It selective Acknowledges datagrams that have been successfully 393 received by the remote node. It serves 2 purposes: 395 - it indicates till a certain datagram that all previous 396 datagrams have been received(without any holes in the 397 sequence) and 399 - it indicates the datagrams sequence ranges which have 400 been received(and so does indicate the holes/gaps between 401 them). It provides us with a form of gap/hole report on 402 messages that have been lost or delayed. A hole can consist 403 of one or more messages. 405 The SACK is always generated and send back to to the sender either 407 - after every second message received(delayed ack). 409 Draft SCTP applicability statement March 2000 411 - after at most 200ms after receiving the last msg. 413 The reason for the holes may be diverse: 415 - simple message loss 417 - different round trip times of messages being transmitted 418 on different interfaces 420 At the sender end, whenever the sender notices a hole in a SACK, it 421 should wait for 3 further SACKs(identifying the same hole) before 422 taking action. This is 3 strikes besides the first one, so that means 423 4. Thus after 4 SACK, the datagrams belonging to the hole should be 424 retransmitted(and only those). 426 The 3 SACKs rule might be relaxed in certain network provided certain 427 condition are met: 429 - private IP network 431 - if the operator felt confident enough of his own closed 432 network. 434 The SACK rule might be configurable in such a networks. This would 435 mean that in case of message drops, retransmission would be "immedi- 436 ate". 438 2.2.6.2 Congestion Control 440 The number of messages in flight is determined by the Congestion 441 window(Cwnd). Every time a msg is SACK, a new msg might be send to 442 the remote side(up till the Cwnd), even if gaps exists which might 443 ultimatly lead to retransmissions. 445 The value of the Cwnd is dependant on the slow start and/or conges- 446 tion avoidance/control. 448 2.2.6.3 Use of Explicit Congestion notification(ECN) 450 Draft SCTP applicability statement March 2000 452 Explicit Congestion control is a experimental method for communicat- 453 ing congestion back to the end node. 455 2.2.6.4 Duplicated messages 457 SACK can get lost. The receiving node would then received duppli- 458 cated packets. A reason for such a behaviour is unbalance between the 459 2 traffic direction, use of different up and down path. 461 2.2.7 Use of the protocol identifier in SCTP 463 Indicates the sort of adaptation layers that is using the associa- 464 tions. The protocol identifier is avialable to the application and is 465 included in each chunk. 0 is the unknown protocol. This protocol id 466 can be used by firewalls for filtering out certain protocols. If 467 firewalls drops certain protocol id then then association will fail 468 in the end because the TSN will be lost. If the chunk(without its 469 user data) is simulated with the TSN in it, then the user data will 470 be dropped, but the association is preserved. 472 The protocol identifier is administreted by IANA. 474 2.2.8 Use of QOS methods 476 SCTP is a end-to-end protocol which cannot guarantee the quality-of- 477 service along the complete path(s) taken by the messages of that par- 478 ticular association. If more guarantees are required for improving 479 the relialability of the transport, some form of QOS mechanism may be 480 needed. 482 The possible schemes are as follows. 484 2.2.8.1 Overprovisioning 486 Overprovisioning of the links so that the total traffic running over 487 over the link never excedes the link capacity. In practice, this may 488 be difficult to ensure reliably. 490 2.2.8.2 Private Internets 492 Use of a private network solely for transport purposes. Private net- 493 works may allow better control and monitoring of resources available. 495 Draft SCTP applicability statement March 2000 497 2.2.8.3 Differentiated services 499 By providing a certain codepoint in the Type-of-service field (TOS), 500 certain Differential services can be selected. [09,10] 502 Setting the code point for transport requires some thought. It is 503 dependant on the kind of differentiate service selected. Also the use 504 of traffic is important: example signalling info should have a higher 505 priorty than the user data traffic for which the signalling is 506 responsible(and that relation does not always exist). 508 2.2.8.4 Integrated services 510 By use of integrated services [08], resources are reserved for sig- 511 naling transport. 513 If resources are unavailable for to initiate a new signaling tran- 514 sport, that request will be denied. In practice, RSVP does not scale 515 well and this solution may prove to be unfeasable. 517 An example is Multi Protocol Label Switching. 519 2.2.9 SCTP Checksum 521 SCTP uses the Adler-32 checksum algorithm. This algorithm will per- 522 form better than a 16 bit(CRC or not) checksum or even a 32 bit CRC 523 checsum. 525 The msg can also be protected by IPSEC. In that case, the checksum 526 migth be turned off(field set to 0). 528 2.2.10 Tunneling of SCTP association over UDP 530 The basic operation of SCTP is to run directly on top of IP. However, 531 due to restrictions placed on implementers by Operating Systems, not 532 all implementations may be able to run over IP directly. Therefore an 533 alternative is given which might circonvent some or all of the res- 534 trictions. 536 The STCP messages are transported over UDP instead. The following 537 issues must be observed: 538 - the portnumber in the UDP header should be the portnumber 540 Draft SCTP applicability statement March 2000 542 assigned to SCTP. The portnumber in the SCTP common header 543 should be the one assigned to the user adaptation layer or to 544 the application of SCTP. This means that portnumbers previously 545 used in UDP and/or TCP can be reused for the same application 546 using SCTP. SCTP DOES NOT change the semantics of the portnumber 547 just because the protocol identifier is added to the SCTP mes- 548 sage. - the checksum field might be used as a additional guard 549 against errors(particular errors in the UDP header). However, 550 the SCTP checksum employed is far better at catching errors, but 551 does not take the UDP header into account. 553 2.2.11 How to define and Use adaptation layers 555 Many different applications may use SCTP for different purposes. They 556 go from Filetransfer over HTTP transport till signalling information 557 transport. 559 Some applications might want to have a unchanged interface with its 560 lower layer(in this case SCTP) while for other applications, this 561 does not pose a problem. A architecture has been devised to let the 562 application chosse whether they want to run over SCTP directly(just a 563 many applications run over TCP) or let application run on top of a 564 adaptation layer over SCTP. 566 The basic architecture is as in Figure 2.11.1 : 568 User/Application level Protocols 569 | | | 570 +------------------------------------+ 571 | User Adaptation modules | 572 +------------------------------------+ 573 | 574 +------------------------------------+ 575 |Simple Control Transmission protocol| 576 +------------------------------------+ 577 | 578 +------------------------------------+ 579 | Standard IP Transport | 580 +------------------------------------+ 581 | 582 Network Layer (IP) 584 Figure 2.11.1: Transport Components 586 Draft SCTP applicability statement March 2000 588 The three components of the transport protocol are : 590 (1) Adaptation modules that support specific primitives, e.g. 591 management indications, required by a particular user/ applica- 592 tion protocol. The use of a adaptation protocol is optional. It 593 is only used in case in which the application protocol does not 594 want to change its interface with the underlaying layer. 596 (2) the Simple Control Transmission Protocol itself that supports a 597 common set of reliable transport functions. 599 (3) a standard IP transport/network protocol provided by the 600 operating system. In some network scenarios, it has been recog- 601 nised that TCP can provide limited (but sufficient) reliable 602 transport functionality for some applications. 604 2.2.12 Security considerations 606 The following aspects of security are : 608 Authentication: 610 Information is sent/received from a known and/or trusted 611 partner. 613 Intergrity: 615 Information may not be modified while in transit. The integrity 616 of a msg in a public network is not guaranteed. 618 Confidentiality: 620 Confidentiality of the user data must be ensured. User data can 621 not be examined by unauthorized users. 623 Availability: 625 The communicating endpoint must remain in service in all 627 Draft SCTP applicability statement March 2000 629 circonstances. Some services have very high availability 630 requirements: example , all SS7 nodes have to remain active for 631 the 99.999% of the time. 633 SCTP only tries to increase the availability of a network. SCTP does 634 not contain any protocol elements in its messages which are directly 635 related to Authentication, Intergrity and Confidentiality functions. 636 It depends for such a features on the IPSEC protocols and architec- 637 ture. 639 The only function which has some bearing on security of SCTP is the 640 integrity of message in SCTP, which is guarded by a Checksum. This 641 checksum is manadatory if IPSEC is NOT used. If IPSEC is used then 642 the SCTP checksum becomes optional. THe use of IPSEC in the SCTP 643 association must in this case be END-TO-END. The use of IPSEC on a 644 part of a path of a SCTP association does NOT relieve SCTP from using 645 the checksum(as this ain't end-to-end transport) 647 The general rule is that IPSEC should be turned on unconditionaly. 649 The description of the internet security architecture and the use of 650 it is described in [06]. 652 3 Recommendations 654 4 References and related work 656 [01] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 657 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, 658 L. and Paxson, V."Simple Control Transmission Protocol", 659 RFCxxxx, March 2000. 661 [02] SG11, ITU-T Recommendation Q.1400, " architecture framework for 662 the development of signaling and OA&M protocols using OSI con- 663 cepts ",1993 665 [03] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995. 667 Draft SCTP applicability statement March 2000 669 [03] Hinden, R. and Deering, S., "IP Version 6 Addressing Architec- 670 ture", RFC 2373, July 1998. 672 [04] Hinden, R. and Deering, S., "Internet Protocol, Version 6 (IPv6) 673 Specification", RFC 2460, December 1998. 675 [05] Clark, D.D., "Names, addresses, ports and routes", RFC 0814, 676 July 1982. 678 [06] Kent, S., and Atkinson, R., "Security Architecture for the 679 Internet Protocol", RFC 2401, November 1998. 681 [07] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery for 682 IP version 6", RFC 1981, August 1996. 684 [08] Mankin, A. Ed., Baker, F., , Braden, B., Bradner, S.,, O`Dell, 685 M., Romanow, A., Weinrib, A. and Zhang, L., "Resource ReSerVa- 686 tion Protocol (RSVP) -- Version 1 Applicability Statement Some 687 Guidelines on Deployment" , RFC 2208, September 1997. 689 [09] Heinanen, J., Baker, F., Weiss, W. and Wroclawski, J., "Assured 690 Forwarding PHB Group", RFC2597, June 1999 692 [10] Jacobson, V., Nichols, K. and Poduri, K., "An Expedited Forward- 693 ing PHB", RFC2598, June 1999 695 5. Acknowledgments 697 The authors wish to thank Renee Revis and many others for their 698 invaluable comments. 700 6 Author's Address 702 Lode Coene 703 Siemens Atea 704 Atealaan 34 705 B-2200 Herentals 706 Belgium 708 Draft SCTP applicability statement March 2000 710 Phone: +32-14-252081 711 EMail: lode.coene@siemens.atea.be 713 John Loughney 714 Nokia 715 Research centre 716 Itamerenkatu 11-13 717 FIN-00180 Helsinki 718 Finland 720 Phone: +358-9-43761 721 EMail: john.loughney@nokia.com 723 Ian Rytina 724 Ericsson Australia 725 37/360 Elizabeth Street 726 Melbourne, Victoria 3000 727 Australia 729 Phone : - 730 EMail:ian.rytina@ericsson.com 732 Lyndon Ong 733 Nortel Networks 734 4401 Great America Parkway 735 Santa Clara, CA 95054 736 USA 738 Phone: - 739 EMail: long@nortelnetworks.com 741 Expires: November 2000 743 Full Copyright Statement 745 Copyright (C) The Internet Society (2000). All Rights Reserved. 747 This document and translations of it may be copied and furnished 748 to 749 others, and derivative works that comment on or otherwise explain 750 it 751 or assist in its implementation may be prepared, copied, published 752 and distributed, in whole or in part, without restriction of any 753 kind, provided that the above copyright notice and this paragraph 755 Draft SCTP applicability statement March 2000 757 are 758 included on all such copies and derivative works. However, this 759 document itself may not be modified in any way, such as by 760 removing 761 the copyright notice or references to the Internet Society or 762 other 763 Internet organizations, except as needed for the purpose of 764 developing Internet standards in which case the procedures for 765 copyrights defined in the Internet Standards process must be 766 followed, or as required to translate it into languages other than 767 English. 769 The limited permissions granted above are perpetual and will not 770 be 771 revoked by the Internet Society or its successors or assigns. 773 This document and the information contained herein is provided on 774 an 775 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 776 ENGINEERING 777 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 778 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 779 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 780 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.