doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc4168.txt b/doc/rfc/rfc4168.txt
new file mode 100644
index 0000000..9843fc4
--- /dev/null
+++ b/doc/rfc/rfc4168.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                       J. Rosenberg
+Request for Comments: 4168                                 Cisco Systems
+Category: Standards Track                                 H. Schulzrinne
+                                                     Columbia University
+                                                            G. Camarillo
+                                                                Ericsson
+                                                            October 2005
+
+
+            The Stream Control Transmission Protocol (SCTP)
+        as a Transport for the Session Initiation Protocol (SIP)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies a mechanism for usage of SCTP (the Stream
+   Control Transmission Protocol) as the transport mechanism between SIP
+   (Session Initiation Protocol) entities.  SCTP is a new protocol that
+   provides several features that may prove beneficial for transport
+   between SIP entities that exchange a large amount of messages,
+   including gateways and proxies.  As SIP is transport-independent,
+   support of SCTP is a relatively straightforward process, nearly
+   identical to support for TCP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 1]
+
+RFC 4168              SCTP as a Transport for SIP           October 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................2
+   3. Potential Benefits ..............................................2
+      3.1. Advantages over UDP ........................................3
+      3.2. Advantages over TCP ........................................3
+   4. Transport Parameter .............................................5
+   5. SCTP Usage ......................................................5
+      5.1. Mapping of SIP Transactions into SCTP Streams ..............5
+   6. Locating a SIP Server ...........................................6
+   7. Security Considerations .........................................7
+   8. IANA Considerations .............................................7
+   9. References ......................................................7
+      9.1. Normative References .......................................7
+      9.2. Informative References .....................................8
+
+1.  Introduction
+
+   The Stream Control Transmission Protocol (SCTP) [4] has been designed
+   as a new transport protocol for the Internet (or intranets) at the
+   same layer as TCP and UDP.  SCTP has been designed with the transport
+   of legacy SS7 signaling messages in mind.  We have observed that many
+   of the features designed to support transport of such signaling are
+   also useful for the transport of SIP (the Session Initiation
+   Protocol) [5], which is used to initiate and manage interactive
+   sessions on the Internet.
+
+   SIP itself is transport-independent, and can run over any reliable or
+   unreliable message or stream transport.  However, procedures are only
+   defined for transport over UDP and TCP.  This document defines
+   transport of SIP over SCTP.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+3.  Potential Benefits
+
+   RFC 3257 presents some of the key benefits of SCTP [10].  We
+   summarize some of these benefits here and analyze how they relate to
+   SIP (a more detailed analysis can be found in [12]).
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 2]
+
+RFC 4168              SCTP as a Transport for SIP           October 2005
+
+
+3.1.  Advantages over UDP
+
+   All the advantages that SCTP has over UDP regarding SIP transport are
+   also shared by TCP.  Below, there is a list of the general advantages
+   that a connection-oriented transport protocol such as TCP or SCTP has
+   over a connection-less transport protocol such as UDP.
+
+   Fast Retransmit: SCTP can quickly determine the loss of a packet,
+      because of its usage of SACK and a mechanism that sends SACK
+      messages faster than normal when losses are detected.  The result
+      is that losses of SIP messages can be detected much faster than
+      when SIP is run over UDP (detection will take at least 500 ms, if
+      not more).  Note that TCP SACK exists as well, and TCP also has a
+      fast retransmit option.  Over an existing connection, this results
+      in faster call setup times under conditions of packet loss, which
+      is very desirable.  This is probably the most significant
+      advantage of SCTP for SIP transport.
+
+
+   Congestion Control: SCTP maintains congestion control over the entire
+      association.  For SIP, this means that the aggregate rate of
+      messages between two entities can be controlled.  When SIP is run
+      over TCP, the same advantages are afforded.  However, when run
+      over UDP, SIP provides less effective congestion control.  This is
+      because congestion state (measured in terms of the UDP retransmit
+      interval) is computed on a transaction-by-transaction basis,
+      rather than across all transactions.  Thus, congestion control
+      performance is similar to opening N parallel TCP connections, as
+      opposed to sending N messages over one TCP connection.
+
+   Transport-Layer Fragmentation: SCTP and TCP provide transport-layer
+      fragmentation.  If a SIP message is larger than the MTU size, it
+      is fragmented at the transport layer.  When UDP is used,
+      fragmentation occurs at the IP layer.  IP fragmentation increases
+      the likelihood of having packet losses and makes NAT and firewall
+      traversal difficult, if not impossible.  This feature will become
+      important if the size of SIP messages grows dramatically.
+
+3.2.  Advantages over TCP
+
+   We have shown the advantages of SCTP and TCP over UDP.  We now
+   analyze the advantages of SCTP over TCP.
+
+   Head of the Line: SCTP is message-based, as opposed to TCP, which is
+      stream-based.  This allows SCTP to separate different signalling
+      messages at the transport layer.  TCP only understands bytes.
+      Assembling received bytes to form signalling messages is performed
+      at the application layer.  Therefore, TCP always delivers an
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 3]
+
+RFC 4168              SCTP as a Transport for SIP           October 2005
+
+
+      ordered stream of bytes to the application.  On the other hand,
+      SCTP can deliver signalling messages to the application as soon as
+      they arrive (when using the unordered service).  The loss of a
+      signalling message does not affect the delivery of the rest of the
+      messages.  This avoids the head of line blocking problem in TCP,
+      which occurs when multiple higher layer connections are
+      multiplexed within a single TCP connection.  A SIP transaction can
+      be considered an application layer connection.  There are multiple
+      transactions running between proxies.  The loss of a message in
+      one transaction should not adversely effect the ability of a
+      different transaction to send a message.  Thus, if SIP is run
+      between entities with many transactions occurring in parallel,
+      SCTP can provide improved performance over SIP over TCP (but not
+      SIP over UDP; SIP over UDP is not ideal from a congestion control
+      standpoint; see above).
+
+   Easier Parsing: Another advantage of message-based protocols, such as
+      SCTP and UDP, over stream-based protocols, such as TCP, is that
+      they allow easier parsing of messages at the application layer.
+      There is no need to establish boundaries (typically using
+      Content-Length headers) between different messages.  However, this
+      advantage is almost negligible.
+
+   Multihoming: An SCTP connection can be associated with multiple IP
+      addresses on the same host.  Data is always sent over one of the
+      addresses, but if it becomes unreachable, data sent to one can
+      migrate to a different address.  This improves fault tolerance;
+      network failures making one interface of the server unavailable do
+      not prevent the service from continuing to operate.  SIP servers
+      are likely to have substantial fault tolerance requirements.  It
+      is worth noting that, because SIP is message oriented and not
+      stream oriented, the existing SRV (Service Selection) procedures
+      defined in [5] can accomplish the same goal, even when SIP is run
+      over TCP.  In fact, SRV records allow the 'connection' to fail
+      over to a separate host.  Since SIP proxies can run statelessly,
+      failover can be accomplished without data synchronization between
+      the primary and its backups.  Thus, the multihoming capabilities
+      of SCTP provide marginal benefits.
+
+   It is important to note that most of the benefits of SCTP for SIP
+   occur under loss conditions.  Therefore, under a zero loss condition,
+   SCTP transport of SIP should perform on par with TCP transport.
+   Research is needed to evaluate under what loss conditions the
+   improvements in setup times and throughput will be observed.
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 4]
+
+RFC 4168              SCTP as a Transport for SIP           October 2005
+
+
+4.  Transport Parameter
+
+   Via header fields carry a transport protocol identifier.  RFC 3261
+   defines the value "SCTP" for SCTP, but does not define the value for
+   the transport parameter for TLS over SCTP.  Note that the value
+   "TLS", defined by RFC 3261, is intended for TLS over TCP.
+
+   Here we define the value "TLS-SCTP" for the transport part of the Via
+   header field to be used for requests sent over TLS over SCTP [8].
+   The updated augmented BNF (Backus-Naur Form) [2] for this parameter
+   is the following (the original BNF for this parameter can be found in
+   RFC 3261):
+
+   transport         =  "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
+                        / other-transport
+
+   The following are examples of Via header fields using "SCTP" and
+   "TLS-SCTP":
+
+     Via: SIP/2.0/SCTP ws1234.example.com:5060
+     Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060
+
+5.  SCTP Usage
+
+   Rules for sending a request over SCTP are identical to TCP.  The only
+   difference is that an SCTP sender has to choose a particular stream
+   within an association in order to send the request (see Section 5.1).
+
+   Note that no SCTP identifier needs to be defined for SIP messages.
+   Therefore, the Payload Protocol Identifier in SCTP DATA chunks
+   transporting SIP messages MUST be set to zero.
+
+   The SIP transport layers of both peers are responsible for managing
+   the persistent SCTP connection between them.  On the sender side, the
+   core or a client (or server) transaction generates a request (or
+   response) and passes it to the transport layer.  The transport sends
+   the request to the peer's transaction layer.  The peer's transaction
+   layer is responsible for delivering the incoming request (or
+   response) to the proper existing server (or client) transaction.  If
+   no server (or client) transaction exists for the incoming message,
+   the transport layer passes the request (or response) to the core,
+   which may decide to construct a new server (or client) transaction.
+
+5.1.  Mapping of SIP Transactions into SCTP Streams
+
+   SIP transactions need to be mapped into SCTP streams in a way that
+   avoids Head Of the Line (HOL) blocking.  Among the different ways of
+   performing this mapping that fulfill this requirement, we have chosen
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 5]
+
+RFC 4168              SCTP as a Transport for SIP           October 2005
+
+
+   the simplest one; a SIP entity SHOULD send every SIP message (request
+   or response) over stream zero with the unordered flag set.  On the
+   receiving side, a SIP entity MUST be ready to receive SIP messages
+   over any stream.
+
+      In the past, it was proposed that SCTP stream IDs be used as
+      lightweight SIP transaction identifiers.  That proposal was
+      withdrawn because SIP now provides (as defined in RFC 3261 [5]) a
+      transaction identifier in the branch parameter of the Via entries.
+      This transaction identifier, missing in the previous SIP spec [9],
+      makes it unnecessary to use the SCTP stream IDs to demultiplex SIP
+      traffic.
+
+   In many circumstances, SIP requires the use of TLS [3], for instance,
+   when routing a SIPS URI [5].  As defined in RFC 3436 [8], TLS running
+   over SCTP MUST NOT use the SCTP unordered delivery service.
+   Moreover, any SIP use of an extra layer between the transport layer
+   and SIP that requires ordered delivery of messages MUST NOT use the
+   SCTP unordered delivery service.
+
+   SIP applications that require ordered delivery of messages from the
+   transport layer (e.g., TLS) SHOULD send SIP messages belonging to the
+   same SIP transaction over the same SCTP stream.  Additionally, they
+   SHOULD send messages belonging to different SIP transactions over
+   different SCTP streams, as long as there are enough available
+   streams.
+
+      A common scenario where the above mechanism should be used
+      consists of two proxies exchanging SIP traffic over a TLS
+      connection using SCTP as the transport protocol.  This works
+      because all of the SIP transactions between the two proxies can be
+      established within one SCTP association.
+
+   Note that if both sides of the association follow this
+   recommendation, when a request arrives over a particular stream, the
+   server is free to return responses over a different stream.  This
+   way, both sides manage the available streams in the sending
+   direction, independently of the streams chosen by the other side to
+   send a particular SIP message.  This avoids undesirable collisions
+   when seizing a particular stream.
+
+6.  Locating a SIP Server
+
+   The primary issue when sending a request is determining whether the
+   next hop server supports SCTP so that an association can be opened.
+   SIP entities follow normal SIP procedures to discover [6] a server
+   that supports SCTP.
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 6]
+
+RFC 4168              SCTP as a Transport for SIP           October 2005
+
+
+   However, in order to use TLS on top of SCTP, an extra definition is
+   needed.  RFC 3263 defines the NAPTR (Naming Authority Pointer) [7]
+   service value "SIP+D2S" for SCTP, but fails to define a value for TLS
+   over SCTP.  Here we define the NAPTR service value "SIPS+D2S" for
+   servers that support TLS over SCTP [8].
+
+7.  Security Considerations
+
+   The security issues raised in RFC 3261 [5] are not worsened by SCTP,
+   provided the advice in Section 5.1 is followed and TLS over SCTP [8]
+   is used where TLS would be required in RFC 3261 [5] or in RFC 3263
+   [6].  So, the mechanisms described in RFC 3436 [8] MUST be used when
+   SIP runs on top of TLS [3] and SCTP.
+
+8.  IANA Considerations
+
+   This document defines a new NAPTR service field value (SIPS+ D2S).
+   The IANA has registered this value under the "Registry for the SIP
+   SRV Resource Record Services Field".  The resulting entry is as
+   follows:
+
+   Services Field        Protocol  Reference
+   --------------------  --------  ---------
+   SIPS+D2S              SCTP      [RFC4168]
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [3]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+        2246, January 1999.
+
+   [4]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
+        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
+        "Stream Control Transmission Protocol", RFC 2960, October 2000.
+
+   [5]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+        Session Initiation Protocol", RFC 3261, June 2002.
+
+   [6]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
+        (SIP): Locating SIP Servers", RFC 3263, June 2002.
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 7]
+
+RFC 4168              SCTP as a Transport for SIP           October 2005
+
+
+   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+        Three: The Domain Name System (DNS) Database", RFC 3403, October
+        2002.
+
+   [8]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
+        Security over Stream Control Transmission Protocol", RFC 3436,
+        December 2002.
+
+9.2.  Informative References
+
+   [9]  Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
+        "SIP: Session Initiation Protocol", RFC 2543, March 1999.
+
+   [10] Coene, L., "Stream Control Transmission Protocol Applicability
+        Statement", RFC 3257, April 2002.
+
+   [11] Camarillo, G., "The Internet Assigned Number Authority (IANA)
+        Uniform Resource Identifier (URI) Parameter Registry for the
+        Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December
+        2004.
+
+   [12] Camarillo, G., Schulrinne, H., and R. Kantola, "Evaluation of
+        Transport Protocols for the Session Initiation Protocol", IEEE,
+        Network vol. 17, no. 5, 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 8]
+
+RFC 4168              SCTP as a Transport for SIP           October 2005
+
+
+Authors' Addresses
+
+   Jonathan Rosenberg
+   Cisco Systems
+   600 Lanidex Plaza
+   Parsippany, NJ  07054
+   US
+
+   Phone: +1 973 952-5000
+   EMail: jdrosen@cisco.com
+   URI:   http://www.jdrosen.net
+
+
+   Henning Schulzrinne
+   Columbia University
+   M/S 0401
+   1214 Amsterdam Ave.
+   New York, NY  10027-7003
+   US
+
+   EMail: schulzrinne@cs.columbia.edu
+
+
+   Gonzalo Camarillo
+   Ericsson
+   Hirsalantie 11
+   Jorvas  02420
+   Finland
+
+   EMail: Gonzalo.Camarillo@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                     [Page 9]
+
+RFC 4168              SCTP as a Transport for SIP           October 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Rosenberg, et al.           Standards Track                    [Page 10]
+