Lode Coene INTERNET DRAFT HansJuergen Schwarzbauer Category: Memo Siemens Title: Greg Sidebottom Date: November 1999 Nortel Networks Ram Dantu Expires: May 2000 Alcatel SCTP applicability guidelines Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This documents defines and discusses the requirements for Internet software using the Simple Control Transmission Protocol. This RFC covers the communications protocol layers: link layer, IP layer, and transport layer. Table of Contents 1. INTRODUCTION .............................................. 1.1 General Considerations ................................ 1.1.1 Robustness Principle ............................. 1.1.2 Security ......................................... 1.1.3 Monitoring and Measurements....................... 1.1.4 Configuration .................................... 1.2 Glossary of terms ..................................... 2. LINK LAYER ................................................. 2.1 INTRODUCTION .......................................... 2.2 SPECIFIC ISSUES ....................................... 2.2.1 Linklayer checksums......... ..................... 2.3 LINK LAYER REQUIREMENTS SUMMARY ....................... 3. INTERNET LAYER PROTOCOLS ................................... 3.1 INTRODUCTION ........................................... 3.2 PROTOCOL WALK-THROUGH ................................. 3.2.1 Internet Protocol -- IP ........................... 3.2.1.1 Version Number .............................. 3.2.1.2 Checksum .................................... 3.2.1.3 Addressing .................................. 3.2.1.4 Fragmentation and Reassembly ................ 3.2.1.5 Identification .............................. 3.2.1.6 Type-of-Service ............................. 3.2.1.7 Time-to-Live ................................ 3.2.1.8 Options ..................................... 3.2.2 Internet Control Message Protocol -- ICMP ......... 3.2.2.1 Destination Unreachable ..................... 3.2.2.2 Redirect .................................... 3.2.2.3 Source Quench ............................... 3.2.2.4 Time Exceeded ............................... 3.2.2.5 Parameter Problem ........................... 3.2.2.6 Echo Request/Reply .......................... 3.2.2.7 Information Request/Reply ................... 3.2.2.8 Timestamp and Timestamp Reply ............... 3.2.2.9 Address Mask Request/Reply .................. 3.2.3 Internet Group Management Protocol IGMP .......... 3.2.4 Internet Routing protocols ....................... 3.3 SPECIFIC ISSUES ....................................... 3.3.1 Routing Outbound Datagrams ....................... 3.3.1.1 Local/Remote Decision ....................... 3.3.1.2 Gateway Selection ........................... 3.3.1.3 Route Cache ................................. 3.3.1.4 Dead Gateway Detection ...................... 3.3.1.5 New Gateway Selection ....................... 3.3.1.6 Initialization .............................. 3.3.2 Reassembly ....................................... 3.3.3 Fragmentation .................................... 3.3.4 Local Multihoming ................................ 3.3.4.1 Introduction ................................ 3.3.4.2 Multihoming Requirements .................... 3.3.4.3 Choosing a Source Address ................... 3.3.5 Source Route Forwarding .......................... 3.3.6 Broadcasts ....................................... 3.3.7 IP Multicasting .................................. 3.3.8 Error Reporting .................................. 3.4 INTERNET LAYER REQUIREMENTS SUMMARY ................... 4. TRANSPORT PROTOCOLS ........................................ 4.1 USER DATAGRAM PROTOCOL -- UDP ......................... 4.1.1 INTRODUCTION ..................................... 4.1.2 PROTOCOL WALK-THROUGH ............................ 4.1.3 SPECIFIC ISSUES .................................. 4.1.3.1 Ports ....................................... 4.1.3.2 IP Options .................................. 4.1.3.3 ICMP Messages ............................... 4.1.3.4 UDP Checksums ............................... 4.1.3.6 Invalid Addresses ............................ 4.1.4 UDP/SCTP LAYER INTERFACE ......................... 4.1.5 UDP REQUIREMENTS SUMMARY ......................... 4.2 SIMPLE COMMON TRANSPORT PROTOCOL -- SCTP............... 4.2.1 INTRODUCTION ..................................... 4.2.2 PROTOCOL WALK-THROUGH ............................ 4.2.2.1 Streams......... ............................ 4.2.2.3 Window Size ................................. 4.2.2.4 SCTP Chuncks................................. 4.2.2.5 Maximum Segment Size Option ................. 4.2.2.6 SCTP Checksum ............................... 4.2.2.7 SCTP state event Diagram .................... 4.2.2.8 Initial Sequence Number Selection............ 4.2.2.9 Closing a Connection ........................ 4.2.2.10 Data Communication ......................... 4.2.2.11 Retransmission Timeout ..................... 4.2.2.12 Managing the Window ........................ 4.2.2.13 Probing Zero Windows ....................... 4.2.2.14 Time to Live ............................... 4.2.2.15 Event Processing ........................... 4.2.2.16 Well-known ports ........................... 4.2.2.17 Sequenced and non-sequenced delivery ....... 4.2.3 SPECIFIC ISSUES .................................. 4.2.3.1 Retransmission Timeout Calculation........... 4.2.3.2 When to Send an ACK Segment ................. 4.2.3.3 When to Send a Window Update ................ 4.2.3.4 When to Send Data ........................... 4.2.3.5 SCTP soft changeover ........................ 4.2.3.6 SCTP Keep-Alives............................. 4.2.3.7 SCTP Multihoming ............................ 4.2.3.8 IP Options .................................. 4.2.3.9 ICMP Messages ............................... 4.2.3.10 Remote Address Validation .................. 4.2.3.11 Congestion control/avoidance ............... 4.2.3.12 Use of QOS methods ......................... 4.2.3.13 Efficiency ................................. 4.2.4 SCTP/APPLICATION LAYER INTERFACE ................. 4.2.4.1 How to define and Use adaptation layers....... 4.2.4.2 Type-of-Service ............................. 4.2.4.3 Flush Call .................................. 4.2.4.4 Multihoming and loadsharing.................. 4.2.5 SCTP REQUIREMENT SUMMARY ......................... 5. References and related work ............................... 6. Authors ................................................... 1. INTRODUCTION /* Editors note: a reference to RFC 2xxx should be the best */ 1.1 General Considerations 1.1.1 Robustness Principle 1.1.2 Security 1.1.3 Monitoring and Measurements 1.1.4 Configuration 1.2 Glossary of terms 2. LINK LAYER 2.1 INTRODUCTION 2.2 SPECIFIC ISSUES 2.2.1 Linklayer checksums /* Editors note: something is required here as most links do have a checksum, but some do not have a checksum */ 2.3 LINK LAYER REQUIREMENTS SUMMARY 4. TRANSPORT PROTOCOLS 4.1 USER DATAGRAM PROTOCOL -- UDP 4.1.1 INTRODUCTION 4.1.2 PROTOCOL WALK-THROUGH 4.1.3 SPECIFIC ISSUES 4.1.3.1 Ports 4.1.3.2 IP Options 4.1.3.3 ICMP Messages 4.1.3.4 UDP Checksums 4.1.3.6 Invalid Addresses 4.1.4 UDP/SCTP LAYER INTERFACE 4.1.5 UDP REQUIREMENTS SUMMARY 4.2 SIMPLE CONTROL TRANSMISSION PROTOCOL -- SCTP 4.2.1 INTRODUCTION The Simple Control Transmission Protocol(SCTP) provides a high relialable, redundant transport between 2 endpoints. The interface between SCTP and its applications is handled via adaptation layers which provide a intermediation layer so that the upper layer protocols of a certain protocol stack architecture does not have to change their interface towards the transport medium and internal functionality when they start using SCTP instead of a other transport protocol Within a asociation between the 2 endpoint, 1 or more stream(s) may be avialable. These streams are not directly visible to the adaptation layers. 4.2.2 PROTOCOL WALK-THROUGH 4.2.2.1 Streams 4.2.2.3 Window Size 4.2.2.4 SCTP Chuncks 4.2.2.5 Maximum Segment Size Option 4.2.2.6 SCTP Checksum 4.2.2.7 SCTP state event Diagram 4.2.2.8 Initial Sequence Number Selection 4.2.2.9 Closing a Connection 4.2.2.10 Data Communication 4.2.2.11 Retransmission Timeout 4.2.2.12 Managing the Window 4.2.2.13 Probing Zero Windows 4.2.2.14 Time to Live 4.2.2.15 Event Processing 4.2.2.16 Well-Known Ports 4.2.2.17 Sequenced / non-sequenced delivery 4.2.3 SPECIFIC ISSUES 4.2.3.1 Retransmission Timeout Calculation 4.2.3.2 When to Send an ACK Segment 4.2.3.3 When to Send a Window Update 4.2.3.4 When to Send Data 4.2.3.5 SCTP soft changeover SCTP streams can perform a soft changover in multihomed operation. When one of the multihomed paths fails, the streams will migrate to one of the still open paths(Soft changeover) without messages loss, except when the timing requirement for that associations are not any longer met. 4.2.3.6 SCTP Keep-Alives If one of the path towards a destination of a multihomed based associations fails and no traffic is running on, then this will only be detected when traffic is switched over from one destination to this destination. Which will lead to message loss. By sending a keepalive message on all the multiple paths that are not used for active transmission of messages accross the association, it is possible for SCTP to detect whether one or more paths have failed. SCTP will not use these paths when a soft changeover is required. The transmission rate of sending keepalive msg should be engineerable and the possible loss of keepalive msg could be used for the monitoring and measurements of the concerned paths. 4.2.3.7 SCTP Multihoming Redundant communication between 2 SCTP endpoints is achieved by using multihoming where the endpoint is able to send/receive over more than one IP address/UDP port. Under the assumption that every IP address/UDP port will have a different path towards the remote endpoint, (this is the responsability of the routing protocols(3.2.4) or of manual configuration), if the transport to one of the IP address/UDP port (= 1 particular path) fails then the traffic can migrate to the other remaining IP address/UDP ports(= other paths). 4.2.3.11 Congestion control & avoidance Congestion control and/or avoidance is of primordial importance in any connectionless network. Congestion is the result of approaching or exceeding the processing capacity of the link, network , application and/or transport layers. If the processing capacity is exceeded, then the congestion can be avoided(example taking a other non-congested path towards the destination) or controlled(example : reducing the rate of messages to that destination). Congestion can be controlled and/or avoided on different levels: - Transport: congestion control/avoidance within SCTP - Network : Congestion control/avoidance present in the layers above the user adaptation layers( example: SCCP, MTP ...) - Link layer: flow control /* ??? */ SCTP conforms to the model of end-to-end congestion control while ISUP and SCCP model themselves on a link and destination based congestion control/overload mechanism. | | | Application and/or transport layer | +---------------------------------------------------+ | A | | | +-------------------------------------+ | ---->| |---- | Network layer | ---->| |---- | +-------------------------------------+ | | | | V +---------------------------------------------------+ | | | Link layer | Fig 2 General Congestion model SCTP associations do not have a fixed capacity assigned to them. The bandwith used/provided by SCTP is dependant on the rest of the traffic(other SCTP, TCP, RTP,UDP... associations) going through the same links of the path followed by the SCTP association. 4.2.3.12 Use of QOS methods SCTP is a end-to-end protocol which cannot guarantee the quality-of-service along the complete path taken by the messages of that particular association. If more guarantees are required for improving the relialability of the transport, some form of QOS mechanism may be needed. (1) Overprovisioning (2) Specific intranet (3) Differentiated services (4) Integrated services 4.2.3.13 Efficiency 4.2.4 SCTP/APPLICATION LAYER INTERFACE 4.2.4.1 How to define and Use adaptation layers /* Editors note: This looks like the place where a part of or the whole draft of Ian could be put concerning the definition and use of adaptation layers see */ 4.2.4.2 Type-of-Service Many types of service are possible with SCTP: - unreliable unsequenced message delivery: same fucntion as UDP./* ?? */ - unsequenced message delivery: the message is relialeble delivered but messages belonging to the same association are not in sequence. - sequenced message delivery: message are relaible delivered and messages belonging to the same association are all in sequence. - transport of streams: streams of bytes can be reliable transported from one end to another end with in sequence guarantee. - messages can be classified according to certain subparameters and transmitted across certain streams. Example: the signalling Link selection field (SLS) of a MTP msg selects a link out of a linkset to a certain destination: here the adaptation layer will select a stream out of the association going to that destination. 4.2.4.3 Flush Call 4.2.4.4 Multihoming and loadsharing 5.0 References and related work [ 1] Promoting the use of End-to-End Congestion control in the Internet. S. Floyd - K. Fall IEEE/ACM Transactions on Networking 1999 Vol x , Nr y 6.0 Authors Lode Coene Siemens Atea Atealaan 34 Herentals, Belgium Phone: +32-14-252081 Email: lode.coene@siemens.atea.be Expires: May 2000 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.