summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6801.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6801.txt')
-rw-r--r--doc/rfc/rfc6801.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc6801.txt b/doc/rfc/rfc6801.txt
new file mode 100644
index 0000000..1b6516f
--- /dev/null
+++ b/doc/rfc/rfc6801.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) U. Kozat
+Request for Comments: 6801 DOCOMO Innovations
+Category: Informational A. Begen
+ISSN: 2070-1721 Cisco
+ November 2012
+
+
+ Pseudo Content Delivery Protocol (CDP) for
+ Protecting Multiple Source Flows in the
+ Forward Error Correction (FEC) Framework
+
+Abstract
+
+ This document provides a pseudo Content Delivery Protocol (CDP) to
+ protect multiple source flows with one or more repair flows based on
+ the Forward Error Correction (FEC) Framework and the Session
+ Description Protocol (SDP) elements defined for the framework. The
+ purpose of the document is not to provide a full-fledged protocol but
+ to show how the defined framework and SDP elements can be combined
+ together to implement a CDP.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6801.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kozat & Begen Informational [Page 1]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Definitions/Abbreviations .......................................3
+ 3. Construction of a Repair Flow from Multiple Source Flows ........3
+ 3.1. Example: Two Source Flows Protected by a Single
+ Repair Flow ................................................6
+ 4. Reconstruction of Source Flows from Repair Flow(s) ..............9
+ 4.1. Example: Multiple Source Flows Protected by a
+ Single Repair Flow .........................................9
+ 5. Security Considerations ........................................10
+ 6. Acknowledgments ................................................10
+ 7. Normative References ...........................................11
+
+
+
+
+
+
+
+
+
+
+
+Kozat & Begen Informational [Page 2]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+1. Introduction
+
+ The Forward Error Correction (FEC) Framework (described in [RFC6363])
+ and SDP Elements for FEC Framework (described in [RFC6364]) together
+ define mechanisms sufficient enough to build an actual Content
+ Delivery Protocol (CDP) with FEC protection. Methods to convey FEC
+ Framework Configuration Information (described in [RFC6695]), on the
+ other hand, provide the signaling protocols that may be used as part
+ of CDP to communicate FEC-Scheme-Specific Information from FEC sender
+ to a single as well as multiple FEC receivers. This document
+ provides a guideline on how the mechanisms defined in [RFC6363] and
+ [RFC6364] can be sufficiently used to design a CDP over a non-trivial
+ scenario, namely, protection of multiple source flows with one or
+ more repair flows.
+
+ In particular, we provide clarifications and descriptions on how:
+
+ o source and repair flows may be uniquely identified,
+
+ o source blocks may be generated from one or more source flows,
+
+ o repair flows may be paired with the source flows,
+
+ o the receiver explicitly and implicitly identifies individual
+ flows, and
+
+ o source blocks are regenerated at the receiver and the missing
+ source symbols in a source block are recovered.
+
+2. Definitions/Abbreviations
+
+ This document uses all the definitions and abbreviations from Section
+ 2 of [RFC6363] minus the RFC 2119 requirements language.
+
+3. Construction of a Repair Flow from Multiple Source Flows
+
+ At the sender side, CDP constructs the source blocks (SBs) by
+ multiplexing transport payloads from multiple flows (see Figures 1
+ and 2). According to the FEC Framework, each source block is FEC-
+ protected separately. Each source block is given to the specific FEC
+ encoder used within the CDP as input and as the outputs Explicit
+ Source FEC Payload ID, Repair FEC Payload ID, and Repair Payloads
+ corresponding to that source block are generated. Note that the
+ Explicit Source FEC Payload ID is optional, and if the CDP has an
+ implicit means of constructing the source block at the sender/
+ receiver (e.g., by using any existing sequence numbers in the
+ payload), the Explicit Source FEC Payload ID might not be output.
+
+
+
+
+Kozat & Begen Informational [Page 3]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+ +------------+
+ s_1 --------> | |
+ . Source | Source | +--------+ +--------+ +--------+
+ . Flows | Block |==> ..|SB_(j+1)| | SB_j | |SB_(j-1)| ..
+ s_n --------> | Generation | +--------+ +--------+ +--------+
+ +------------+
+
+ Figure 1: Source Block Generation for a FEC Scheme
+
+ Figure 2 shows the structure of a source block. A CDP must clearly
+ specify which payload corresponds to which source flow and the length
+ of each payload.
+
+
+ <------------------ Source Block (SB) ------------------->
+
+ +-------...-----+-------...-----+- -+-------...-----+
+ | Payload_1 | Payload_2 | . . . | Payload_n |
+ +-------...-----+-------...-----+- -+-------...-----+
+ \______ _______|______ _______| |______ _______|
+ \/ \/ \/
+ FID_1,Len_1 FID_2,Len_2 FID_n,Len_n
+
+ Figure 2: Structure of a Source Block
+
+ The Flow ID (FID) value provides a unique shorthand identifier for
+ the source flows. FID is specified and associated with the possibly
+ wildcarded tuple of {source IP address, source port, destination IP
+ address, destination port, transport protocol} in the SDP
+ description. When wildcarded, certain fields in the tuple are not
+ needed for distinguishing the source flows. The tuple is carried in
+ the IP and transport headers of the source packets. Since FID is
+ utilized by the CDP and FEC scheme to distinguish between the source
+ packets, the tuple must have a one-to-one mapping to a valid FID.
+ This point will be clearer in the specific example given later in
+ this section. The length of FID must be a priori fixed and known to
+ both the receiver and sender. Alternatively, it might be specified
+ in the FEC-Scheme-Specific Information field in the SDP element
+ [RFC6364].
+
+ The payload length (Len) information is needed to figure out how many
+ bits, bytes, or symbols (depending on the FEC scheme) from a
+ particular source flow are included in the source block. If the
+ payload is not an integer multiple of the specified symbol length,
+ the remaining portion is padded with zeros (see Figures 3 and 4).
+
+
+
+
+
+
+Kozat & Begen Informational [Page 4]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+ +------+
+ +--------+ +--------+ +--------+ | | -------> r_1
+ .. |SB_(j+1)| | SB_j | |SB_(j-1)| .. ==> | FEC | Repair .
+ +--------+ +--------+ +--------+ |Scheme| Flows .
+ | | -------> r_k
+ +------+
+
+ Figure 3: Repair Flow Generation by a FEC Scheme
+
+
+ <------------------ Source Block (SB) ------------------->
+ | | | | | |
+ +-------...-----+-------...-----+- -+-------...-----+ |
+ | Payload_1 | Payload_2 | . . . | Payload_n |0|
+ +-------...-----+-------...-----+- -+-------...-----+ |
+ | | | | | |
+ | Symbol_1 | Symbol_2 | Symbol_3 | . . . | Symbol_m |
+ |<-------->|<-------->|<-------->| |<-------->|
+
+ +------+
+ Symbol_1,..,Symbol_m => | FEC | => Symbol_u,..,Symbol_1
+ | Enc. |
+ +------+
+
+ Figure 4: Repair Flow Payload Generation
+
+ FEC schemes typically expect a source block of certain size, say, m
+ symbols. Therefore, the FEC encoder divides each source block into m
+ symbols (with some padding if the source block is shorter than the
+ expected m symbols) and generates u repair symbols, which are
+ functions of the m symbols in the original source block. The repair
+ symbols are grouped by the FEC scheme into repair payloads with each
+ repair payload assigned a Repair FEC Payload ID in order to associate
+ each repair payload with a particular source block at the receiver.
+ If the payloads in a given source block have sequence numbers that
+ can uniquely specify their location in the source block, an Explicit
+ Source FEC Payload ID may not be generated for these payloads.
+ Otherwise, Explicit Source FEC Payload IDs are generated for each
+ payload and indicate the order the payloads appear in the source
+ block.
+
+ Note that FID and length information are not actually transmitted
+ with the source payloads since both information can be gathered by
+ other means as it will be clear in the next sections.
+
+
+
+
+
+
+
+Kozat & Begen Informational [Page 5]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+3.1. Example: Two Source Flows Protected by a Single Repair Flow
+
+ In this section, we present an example of source flow and repair flow
+ generation by the CDP. We have two source flows with flow IDs of 0
+ and 1 to be protected by a single repair flow (see Figure 5). The
+ first source flow is multicast to 233.252.0.1, and the second source
+ flow is multicast to 233.252.0.2. Both flows use the port number
+ 30000.
+
+
+ SOURCE FLOWS
+ S1: Source Flow | | INSTANCE #1
+ |---------| R3: Repair Flow
+ S2: Source Flow |
+
+ Figure 5: Example: Two Source Flows and One Repair Flow
+
+ The SDP description below states that the source flow defined by the
+ tuple {*,*,233.252.0.1,30000} is identified with FID=0 and the source
+ flow defined by the tuple {*,*,233.252.0.2,30000} is identified with
+ FID=1 (via the 'id' parameter of the "fec-source-flow" attribute).
+ The SDP description also states that the repair flow is to be
+ received at the multicast address of 233.252.0.3 and at port 30000.
+
+ v=0
+ o=ali 1122334455 1122334466 IN IP4 fec.example.com
+ s=FEC Framework Examples
+ t=0 0
+ a=group:FEC-FR S1 S2 R3
+ m=video 30000 RTP/AVP 100
+ c=IN IP4 233.252.0.1/127
+ a=rtpmap:100 MP2T/90000
+ a=fec-source-flow: id=0
+ a=mid:S1
+ m=video 30000 RTP/AVP 101
+ c=IN IP4 233.252.0.2/127
+ a=rtpmap:101 MP2T/90000
+ a=fec-source-flow: id=1
+ a=mid:S2
+ m=application 30000 UDP/FEC
+ c=IN IP4 233.252.0.3/127
+ a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
+ a=repair-window:150ms
+ a=mid:R3
+
+ Figure 6 shows the first and the second source blocks (SB_1 and SB_2)
+ generated from these two source flows. In this example, SB_1 is of
+ length 10000 bytes. Suppose that the FEC scheme uses a symbol length
+
+
+
+Kozat & Begen Informational [Page 6]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+ of 512 bytes. Then, SB_1 can be divided into 20 symbols after
+ padding the source block for 240 bytes. Assume that the FEC scheme
+ is rate-2/3 erasure code; hence, it generates 10 repair symbols from
+ 20 original symbols for SB_1. On the other hand, SB_2 is 7000 bytes
+ long and can be divided into 14 symbols after padding 168 bytes.
+ Using the same encoder, suppose that seven repair symbols are
+ generated for SB_2.
+
+ <-------- Source Block 1 -------->
+ +------------+-------------------+
+ | $1 $2 $3 $4| #1 #2 #3 #4 #5 #6 | 0..00
+ +------------+-------------------+
+ \__________________ __________________/
+ \/
+ @1 @2 @3 @4 @5 @6 @7 @8 @9 @10
+
+
+ <---- Source Block 2 ---->
+ +----------------+-------+
+ | $5 $6 $7 $8 $9 | #7 #8 |0..00
+ +----------------+-------+
+ \______________ _____________/
+ \/
+ @11 @12 @13 @14 @15 @16 @17
+
+ $: 1000-byte payload from source flow 1
+ #: 1000-byte payload from source flow 2
+ @: Repair symbol
+
+ Figure 6: Source Block with Two Source Flows
+
+ The information on the unit of payload length, FEC scheme, symbol
+ size, and coding rates can be specified in the FEC-Scheme-Specific
+ Information (FSSI) field of the SDP element. If the values of the
+ payload lengths from each source flow and the order of appearance of
+ source flows in every source block are fixed during the session,
+ these values may be also provided in the FSSI field. To carry FSSI
+ information to the FEC receivers, one may use the signaling methods
+ described in [RFC6695]. In our example, we will consider the case
+ where the ordering is fixed and known both at the sender and the
+ receiver, but the payload lengths will be variable from one source
+ block to another. We assume that the payload of a source flow with
+ an FID smaller than another flow's FID precedes other payloads in a
+ source block.
+
+ The FEC scheme gets the source blocks as input and generates the
+ parity blocks for each source block to protect the whole source
+ block. In the example, the repair payloads for SB_1 consist of 512-
+
+
+
+Kozat & Begen Informational [Page 7]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+ byte symbols, denoted by @1 to @10. Similarly, @11 to @17
+ constitutes the repair payloads for SB_2. The FEC scheme outputs the
+ repair payloads along with the Repair FEC Payload IDs. In our
+ example, Repair FEC Payload ID provides information on the source
+ block sequence number and the order the repair symbols are generated.
+ For instance, @3 is the third FEC repair symbol for SB_1, and the
+ three tuple {@3,SB_1,3} can uniquely deliver this information. In
+ our example, the FEC scheme also provides Explicit Source FEC Payload
+ IDs that carry information to indicate which source symbols
+ correspond to which source block sequence number and the relative
+ position in the source block. For instance, the two tuple {SB_2,2}
+ can be attached to $6 as the Explicit Source FEC Payload ID to
+ indicate that $6 is protected together with packets belonging to
+ SB_2, and $6 is the second payload in SB_2.
+
+ The source packets are generated from the source symbols by
+ concatenating consecutive symbols in one packet. There should not be
+ any fragmentation of a source symbol; e.g., symbols #7 and #8 can be
+ concatenated in one transport payload of 2000 bytes (the
+ implementation should make sure that the size of the resulting source
+ packet -- payload plus the overhead -- is not larger than the path
+ MTU), but one portion of symbol #7 should not be put in one source
+ packet and the remaining portion in another source packet. The
+ simplest implementation is to place each source symbol in a different
+ source packet as shown in Figure 7.
+
+ +------------------------------------+
+ | IP header {233.252.0.1} |
+ +------------------------------------+
+ | Transport header {30000} |
+ +------------------------------------+
+ | Original Transport Payload {$6} |
+ +------------------------------------+
+ | Source FEC Payload ID {SB_2,2} |
+ +------------------------------------+
+
+ Figure 7: Example of a Source Packet for IPv4
+
+ The repair packets are generated from the repair symbols belonging to
+ the same source block by grouping consecutive symbols in one packet.
+ There should not be any fragmentation of a repair symbol; e.g.,
+ symbols @4, @5, and @6 can be concatenated in one transport payload
+ of 1536 bytes, but @6 should not be divided into smaller sub-symbols
+ and spread over multiple repair packets. The Repair FEC Payload ID
+ must carry sufficient information for the decoding process. In our
+ example, for instance, indicating source block sequence number,
+ length of each source payload, and the order that the first parity
+ symbol in the repair packet among all the parity symbols generated
+
+
+
+Kozat & Begen Informational [Page 8]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+ for the same source block is sufficient. The exact header format of
+ Repair FEC Payload ID may be specified in the FSSI field of the SDP
+ element. In Figure 8, for instance, the repair symbols @4, @5, and
+ @6 are concatenated together. The Payload ID {SB_1,4,4,6} states
+ that the repair symbols protect SB_1, the first repair symbol in the
+ payload is generated as the fourth symbol and the source block
+ consists of two source flows carrying four and six packets from each.
+
+ +------------------------------------+
+ | IP header {233.252.0.3} |
+ +------------------------------------+
+ | Transport header {30000} |
+ +------------------------------------+
+ | Repair FEC Payload ID {SB_1,4,4,6} |
+ +------------------------------------+
+ | Repair Symbols {@4,@5,@6} |
+ +------------------------------------+
+
+ Figure 8: Example of a Repair Packet for IPv4
+
+4. Reconstruction of Source Flows from Repair Flow(s)
+
+ Here we provide an example for reconstructing multiple source flows
+ from a single repair flow.
+
+4.1. Example: Multiple Source Flows Protected by a Single Repair Flow
+
+ At the receiver, source flows 1 and 2 are received at
+ {233.252.0.1,30000} and {233.252.0.2,30000}, while the repair flow is
+ received at {233.252.0.3,30000}. The CDP can map these tuples to the
+ flow IDs using the SDP elements. Accordingly, the payloads received
+ at {233.252.0.1,30000} and {233.252.0.2,30000} are mapped to flow IDs
+ 0 and 1, respectively.
+
+ The CDP passes the flow IDs and received payloads along with the
+ Explicit Source FEC Payload ID to the FEC scheme defined in the SDP
+ description. The CDP also passes the received repair packet payloads
+ and Repair FEC Payload ID to the FEC scheme. The FEC scheme can
+ construct the original source block with missing packets by using the
+ information given in the FEC Payload IDs. The FEC Repair Payload ID
+ provides the information that SB_1 has packets from two flows with
+ four packets from the first one and six packets from the second one.
+ Flow IDs state that the packets from source flow 0 precede the
+ packets from source flow 1. Explicit Source FEC Payload IDs, on the
+ other hand, provide the information about which source payload
+ appears in what order. Therefore, the FEC scheme can depict a source
+ block with exact locations of the missing packets. Figure 9 depicts
+ the case for SB_1. Since the original source block with missing
+
+
+
+Kozat & Begen Informational [Page 9]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+ packets can be constructed at the decoder and the FEC scheme knows
+ the coding rate (e.g., it might be carried in the FSSI field in the
+ SDP description), a proper decoding operation can start as soon as
+ the repair symbols are provided to the FEC scheme.
+
+ <-------- Source Block 1 -------->
+ +------------+-------------------+
+ | $1 $2 X X | #1 X #3 #4 #5 #6 |
+ +------------+-------------------+
+
+ O: Symbols received from the source flow 1 for SB_1
+ #: Symbols received from the source flow 2 for SB_1
+ X: Lost source symbols
+
+ Figure 9: Source Block Regeneration
+
+ When the FEC scheme can recover any missing symbol while more repair
+ symbols are arriving, it provides the recovered blocks along with the
+ source flow IDs of the recovered blocks as outputs to the CDP. The
+ receiver knows how long to wait to repair the remaining missing
+ packets (e.g., specified by the 'repair-window' attribute in the SDP
+ description). After the associated timer expires, the CDP hands over
+ whatever could be recovered from the source flow to the application
+ layer and continues with processing the next source block.
+
+5. Security Considerations
+
+ For the general security considerations related to the FEC Framework,
+ refer to [RFC6363]. For the security considerations related to the
+ SDP elements in the FEC Framework, refer to [RFC6364]. There are no
+ additional security considerations that apply to this document.
+
+6. Acknowledgments
+
+ The authors would like to thank the FEC Framework design team for
+ their inputs, suggestions, and contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kozat & Begen Informational [Page 10]
+
+RFC 6801 Pseudo CDP for Multiple Source Flows November 2012
+
+
+7. Normative References
+
+ [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
+ Correction (FEC) Framework", RFC 6363, October 2011.
+
+ [RFC6364] Begen, A., "Session Description Protocol Elements for the
+ Forward Error Correction (FEC) Framework", RFC 6364,
+ October 2011.
+
+ [RFC6695] Asati, R., "Methods to Convey Forward Error Correction
+ (FEC) Framework Configuration Information", RFC 6695,
+ August 2012.
+
+
+Authors' Addresses
+
+ Ulas C. Kozat
+ DOCOMO Innovations
+ 3240 Hillview Avenue
+ Palo Alto, CA 94304-1201
+ USA
+
+ Phone: +1 650 496 4739
+ EMail: kozat@docomolabs-usa.com
+
+
+ Ali Begen
+ Cisco
+ 181 Bay Street
+ Toronto, ON M5J 2T3
+ Canada
+
+ EMail: abegen@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kozat & Begen Informational [Page 11]
+