One document matched: draft-coene-sctp-applic-state-00.txt
Lode Coene
INTERNET DRAFT HansJuergen Schwarzbauer
Category: Memo Siemens
Title: <draft-coene-sctp-applic-state-00.txt> Greg Sidebottom
Date: November 1999 Nortel Networks
Ram Dantu
Expires: May 2000 Alcatel
SCTP applicability guidelines
<draft-coene-sctp-applic-state-00.txt>
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 <draft-rytina-sigtran-generic-framework-v00.txt >
*/
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.
| PAFTECH AB 2003-2026 | 2026-04-23 04:18:36 |