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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/