doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc3524.txt b/doc/rfc/rfc3524.txt
new file mode 100644
index 0000000..9641608
--- /dev/null
+++ b/doc/rfc/rfc3524.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                       G. Camarillo
+Request for Comments: 3524                                     A. Monrad
+Category: Standards Track                                       Ericsson
+                                                              April 2003
+
+
+         Mapping of Media Streams to Resource Reservation Flows
+
+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 (2003).  All Rights Reserved.
+
+Abstract
+
+   This document defines an extension to the Session Description
+   Protocol (SDP) grouping framework.  It allows requesting a group of
+   media streams to be mapped into a single resource reservation flow.
+   The SDP syntax needed is defined, as well as a new "semantics"
+   attribute called Single Reservation Flow (SRF).
+
+Table of Contents
+
+   1.  Introduction ........................................    2
+       1.1  Terminology ....................................    2
+   2.  SRF Semantics .......................................    2
+   3.  Applicability Statement .............................    3
+   4.  Examples ............................................    3
+   5.  IANA Considerations .................................    4
+   6.  Security Considerations .............................    4
+   7.  Acknowledgements ....................................    4
+   8.  Normative References ................................    5
+   9.  Informative References ..............................    5
+   10. Authors' Addresses ..................................    5
+   11. Full Copyright Statement ............................    6
+
+
+
+
+
+
+
+
+
+Camarillo & Monrad          Standards Track                     [Page 1]
+
+RFC 3524  Mapping Media Streams to Resource Reservation Flows April 2003
+
+
+1.  Introduction
+
+   Resource reservation protocols assign network resources to particular
+   flows of IP packets.  When a router receives an IP packet, it applies
+   a filter in order to map the packet to the flow it belongs.  The
+   router provides the IP packet with the Quality of Service (QoS)
+   corresponding to its flow.  Routers typically use the source and the
+   destination IP addresses and port numbers to filter packets.
+
+   Multimedia sessions typically contain multiple media streams (e.g. an
+   audio stream and a video stream).  In order to provide QoS for a
+   multimedia session it is necessary to map all the media streams to
+   resource reservation flows.  This mapping can be performed in
+   different ways.  Two possible ways are to map all the media streams
+   to a single resource reservation flow or to map every single media
+   stream to a different resource reservation flow.  Some applications
+   require that the former type of mapping is performed while other
+   applications require the latter.  It is even possible that a mixture
+   of both mappings is required for a particular media session.  For
+   instance, a multimedia session with three media streams might require
+   that two of them are mapped into a single reservation flow while the
+   third media stream uses a second reservation flow.
+
+   This document defines the SDP [1] syntax needed to express how media
+   streams need to be mapped into reservation flows.  For this purpose,
+   we use the SDP grouping framework [2] and define a new "semantics"
+   attribute called Single Reservation Flow (SRF).
+
+1.1 Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
+   [3] and indicate requirement levels for compliant SIP
+   implementations.
+
+2.  SRF Semantics
+
+   We define a new "semantics" attribute within the SDP grouping
+   framework [2]: Single Reservation Flow (SRF).
+
+   Media lines grouped using SRF semantics SHOULD be mapped into the
+   same resource reservation flow.  Media lines that do not belong to a
+   particular SRF group SHOULD NOT be mapped into the reservation flow
+   used for that SRF group.
+
+
+
+
+
+
+Camarillo & Monrad          Standards Track                     [Page 2]
+
+RFC 3524  Mapping Media Streams to Resource Reservation Flows April 2003
+
+
+   Note that an SRF group MAY consist of a single media line.  In that
+   case, following the definition above, that media line will be mapped
+   into one reservation flow.  That reservation flow will carry traffic
+   from that media line, and from no other media lines.
+
+3. Applicability Statement
+
+   The way resource reservation works in some scenarios makes it
+   unnecessary to use the mechanism described in this document.  Some
+   resource reservation protocols allow the entity generating the SDP
+   session description to allocate resources in both directions (i.e.,
+   sendrecv) for the session.  In this case, the generator of the
+   session description can chose any particular mapping of media flows
+   and reservation flows.
+
+   The mechanism described in this document is useful when the remote
+   party needs to be involved in the resource reservation.
+
+4.  Examples
+
+   For this example, we have chosen to use SIP [4] to transport SDP
+   sessions and RSVP [5] to establish reservation flows.  However, other
+   protocols or mechanisms could be used instead without affecting the
+   SDP syntax.
+
+   A user agent receives a SIP INVITE with the SDP below:
+
+      v=0
+      o=Laura 289083124 289083124 IN IP4 one.example.com
+      t=0 0
+      c=IN IP4 192.0.0.1
+      a=group:SRF 1 2
+      m=audio 30000 RTP/AVP 0
+      a=mid:1
+      m=video 30002 RTP/AVP 31
+      a=mid:2
+
+   This user agent uses RSVP to perform resource reservation.  Since
+   both media streams are part of an SRF group, the user agent will
+   establish a single RSVP session.  An RSVP session is defined by the
+   triple:  (DestAddress, ProtocolId[, DstPort]).  Table 1 shows the
+   parameters used to establish the RSVP session.
+
+   If the same user agent received an SDP session description with the
+   same media streams but without the group line, it would be free to
+   map the two media streams into two different RSVP sessions.
+
+
+
+
+
+Camarillo & Monrad          Standards Track                     [Page 3]
+
+RFC 3524  Mapping Media Streams to Resource Reservation Flows April 2003
+
+
+      Session Number  DestAddress  ProtocolId  DstPort
+      ________________________________________________
+            1          192.0.0.1      UDP        any
+
+      Table 1: Parameters needed to establish the RSVP session
+
+5.  IANA Considerations
+
+   IANA has registered the following new "semantics" attribute for the
+   SDP grouping framework [2].  It has been registered in the SDP
+   parameters registry (http://www.iana.org/assignments/sdp-parameters)
+   under Semantics for the "group" SDP Attribute:
+
+   Semantics                  Token      Reference
+   -------------------        -----      ---------
+   Single Reservation flow     SRF       [RFC3524]
+
+6.  Security Considerations
+
+   An attacker adding group lines using the SRF semantics to an SDP
+   session description could force a user agent to establish a larger or
+   a smaller number of resource reservation flows than needed.  This
+   could consume extra resources in the end-point or degrade the quality
+   of service for a particular session.  It is thus STRONGLY RECOMMENDED
+   that integrity protection be applied to the SDP session descriptions.
+   For session descriptions carried in SIP, S/MIME is the natural choice
+   to provide such end-to-end integrity protection, as described in RFC
+   3261 [4]. Other applications MAY use a different form of integrity
+   protection.
+
+7.  Acknowledgements
+
+   Jonathan Rosenberg provided useful comments about the applicability
+   of the mechanism described in this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo & Monrad          Standards Track                     [Page 4]
+
+RFC 3524  Mapping Media Streams to Resource Reservation Flows April 2003
+
+
+8.  Normative References
+
+   [1]  Handley, M. and V. Jacobson, "SDP: Session Description
+        Protocol", RFC 2327, April 1998.
+
+   [2]  Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne,
+        "Grouping of Media Lines in the Session Description Protocol
+        (SDP)", December 2002.
+
+   [3]  Bradner, S., "Key words for use in RFCs to indicate requirement
+        levels", BCP 14, RFC 2119, March 1997.
+
+9.  Informative References
+
+   [4]  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.
+
+   [5]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
+        "Resource ReSerVation protocol (RSVP) -- Version 1 Functional
+        Specification", RFC 2205, September 1997.
+
+10.  Authors' Addresses
+
+   Gonzalo Camarillo
+   Ericsson
+   Advanced Signalling Research Lab.
+   FIN-02420 Jorvas
+   Finland
+
+   EMail:  Gonzalo.Camarillo@ericsson.com
+
+
+   Atle Monrad
+   Ericsson
+   N-4898 Grimstad
+   Norway
+
+   EMail:  atle.monrad@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo & Monrad          Standards Track                     [Page 5]
+
+RFC 3524  Mapping Media Streams to Resource Reservation Flows April 2003
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Camarillo & Monrad          Standards Track                     [Page 6]
+