draft-ietf-fecframe-pseudo-cdp-00.txt   draft-ietf-fecframe-pseudo-cdp-01.txt 
FEC Framework U. Kozat FEC Framework U. Kozat
Internet-Draft DoCoMo USA Labs Internet-Draft DoCoMo USA Labs
Intended status: Standards Track A. Begen Intended status: Standards Track A. Begen
Expires: April 30, 2009 Cisco Systems Expires: September 8, 2009 Cisco Systems
October 27, 2008 March 7, 2009
Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source
Flows in FEC Framework Flows in FEC Framework
draft-ietf-fecframe-pseudo-cdp-00 draft-ietf-fecframe-pseudo-cdp-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2009. This Internet-Draft will expire on September 8, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 document and the Session Description Protocol (SDP) the FEC Framework document and the Session Description Protocol (SDP)
elements defined for the framework. The purpose of the document is elements defined for the framework. The purpose of the document is
not to provide a full-pledged protocol, but to show how the defined not to provide a full-pledged protocol, but to show how the defined
framework and SDP elements can be combined together to design a CDP. framework and SDP elements can be combined together to design a CDP.
skipping to change at page 2, line 21 skipping to change at page 3, line 4
4.1. Example: Two Source Flows Protected by a Single Repair 4.1. Example: Two Source Flows Protected by a Single Repair
Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Reconstruction of Source Flows from Repair Flow(s) . . . . . . 10 5. Reconstruction of Source Flows from Repair Flow(s) . . . . . . 10
5.1. Example: Multiple Source Flows Protected by a Single 5.1. Example: Multiple Source Flows Protected by a Single
Repair Flow . . . . . . . . . . . . . . . . . . . . . . . 10 Repair Flow . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
The Forward Error Correction (FEC) Framework (described in The Forward Error Correction (FEC) Framework (described in
[I-D.ietf-fecframe-framework]) and SDP Elements for FEC Framework [I-D.ietf-fecframe-framework]) and SDP Elements for FEC Framework
(described in [I-D.ietf-fecframe-sdp-elements]) together define (described in [I-D.ietf-fecframe-sdp-elements]) together define
mechanisms sufficient enough to build an actual Content Delivery mechanisms sufficient enough to build an actual Content Delivery
Protocol (CDP). This document aims at providing a guideline on how Protocol (CDP) with FEC protection. Methods to convey FEC Framework
the mechanisms defined in each document become useful over a non- Configuration Information (described in
trivial scenario, namely protection of multiple source flows with one [I-D.ietf-fecframe-config-signaling]) on the other hand provides the
or more repair flows. 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 aims at providing a
guideline on how the mechanisms defined in
[I-D.ietf-fecframe-framework] and [I-D.ietf-fecframe-sdp-elements]
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: 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
skipping to change at page 7, line 32 skipping to change at page 7, line 35
c=IN IP4 224.1.1.2/127 c=IN IP4 224.1.1.2/127
a=rtpmap:101 MP2T/90000 a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1 a=fec-source-flow: id=1
a=mid:S2 a=mid:S2
m=application 30000 udp/fec m=application 30000 udp/fec
c=IN IP4 224.1.2.1/127 c=IN IP4 224.1.2.1/127
a=fec-repair-flow: encoding-id=0; ss-fssi=5hu= a=fec-repair-flow: encoding-id=0; ss-fssi=5hu=
a=repair-window: 200 a=repair-window: 200
a=mid:R1 a=mid:R1
Figure 7 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 padding
the source block for 240 bytes. Assume that the FEC scheme is 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 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-byte long original symbols for SB_1. On the other hand, SB_2 is 7000-byte long
and can be divided into 14 symbols after padding 168 bytes. Using and can be divided into 14 symbols after padding 168 bytes. Using
the same encoder, suppose that 7 repair symbols are generated for the same encoder, suppose that 7 repair symbols are generated for
SB_2. SB_2.
skipping to change at page 8, line 25 skipping to change at page 8, line 25
| $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 7: 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. In our example, these values may be also provided in the FSSI field. To carry FSSI
we will consider the case where the ordering is fixed and known both information to the FEC receivers, one may utilize the signaling
at the sender and the receiver, but the payload lengths will be methods described in [I-D.ietf-fecframe-config-signaling]. In our
variable from one source block to another. We assume that the example, we will consider the case where the ordering is fixed and
payload of a source flow with an FID smaller than another flow's FID known both at the sender and the receiver, but the payload lengths
precedes other payloads in a source block. 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 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 constitute
the repair payloads for SB_2. The FEC scheme outputs the repair the repair payloads for SB_2. The FEC scheme outputs the repair
payloads along with the Repair FEC Payload IDs. In our example, payloads along with the Repair FEC Payload IDs. In our example,
Repair FEC Payload ID provides information on the source block Repair FEC Payload ID provides information on the source block
sequence number and the order the repair symbols are generated. For 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 instance @3 is the third FEC repair symbol for SB_1 and the three
skipping to change at page 9, line 18 skipping to change at page 9, line 20
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 8. source packet as shown in Figure 7.
+------------------------------------+ +------------------------------------+
| IP header {224.1.1.1} | | IP header {224.1.1.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 8: Example of a source packet Figure 7: Example of a source packet
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 and in our
example indicating source block sequence number, length of each example indicating source block sequence number, length of each
source payload, and the order that the first parity block in a repair source payload, and the order that the first parity block in a repair
packet is generated are sufficient. The exact header format of packet is generated are 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 9 for instance, the repair symbols @4, @5, and @6 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 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 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 4th symbol and the source block consists
of two source flows carrying 4 and 6 packets from each. of two source flows carrying 4 and 6 packets from each.
+------------------------------------+ +------------------------------------+
| IP header {224.1.2.1} | | IP header {224.1.2.1} |
+------------------------------------+ +------------------------------------+
| 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 9: Example of a repair packet Figure 8: Example of a repair packet
5. Reconstruction of Source Flows from Repair Flow(s) 5. Reconstruction of Source Flows from Repair Flow(s)
5.1. Example: Multiple Source Flows Protected by a Single Repair Flow 5.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
{224.1.1.1,30000} and {224.1.1.2,30000}, while the repair flow is {224.1.1.1,30000} and {224.1.1.2,30000}, while the repair flow is
received at {224.1.2.1,30000}. The CDP can map these tuples to the received at {224.1.2.1,30000}. The CDP can map these tuples to the
flow IDs using the SDP elements. Accordingly, the payloads received flow IDs using the SDP elements. Accordingly, the payloads received
at {224.1.1.1,30000} and {224.1.1.2,30000} are mapped to flow IDs 0 at {224.1.1.1,30000} and {224.1.1.2,30000} are mapped to flow IDs 0
skipping to change at page 10, line 40 skipping to change at page 10, line 40
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 4
packets from the first one and 6 packets from the second one. Flow packets from the first one and 6 packets from the second one. Flow
IDs state that the packets from source flow 0 precedes the packets IDs state that the packets from source flow 0 precedes the packets
from source flow 1. Explicit Source FEC Payload IDs on the other from source flow 1. Explicit Source FEC Payload IDs on the other
hand provide the information about which source payload appears in hand provide the information about which source payload appears in
what order. Therefore, the FEC scheme can depict an source block what order. Therefore, the FEC scheme can depict an source block
with exact locations of the missing packets. Figure 10 depicts the with exact locations of the missing packets. Figure 9 depicts the
case for SB_1. Since the original source block with missing packets case for SB_1. Since the original source block with missing packets
can be constructed at the decoder and the FEC scheme knows the coding 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 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 description), a proper decoding operation can start as soon as the
repair symbols are provided to the FEC scheme. 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 10: Source block regeneration Figure 9: Source block regeneration
When the FEC scheme can recover any missing block while more repair When the FEC scheme can recover any missing block 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.
6. Security Considerations 6. Security Considerations
TBC. For the general security considerations related to the FEC Framework,
refer to [I-D.ietf-fecframe-framework]. There are no additional
security considerations that apply to this document.
7. IANA Considerations 7. IANA Considerations
TBC. There are no IANA related issues considered in this document.
8. Acknowledgments 8. Acknowledgments
TBC. The authors would like to thank the FEC Framework Design Team for
their inputs, suggestions and contributions.
9. Normative References 9. Normative References
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework", Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-03 (work in progress), draft-ietf-fecframe-framework-03 (work in progress),
October 2008. October 2008.
[I-D.ietf-fecframe-sdp-elements] [I-D.ietf-fecframe-sdp-elements]
Begen, A., "SDP Elements for FEC Framework", Begen, A., "SDP Elements for FEC Framework",
draft-ietf-fecframe-sdp-elements-01 (work in progress), draft-ietf-fecframe-sdp-elements-02 (work in progress),
July 2008. November 2008.
[I-D.ietf-fecframe-config-signaling]
Asati, R., "Methods to convey FEC Framework Configuration
Information", draft-ietf-fecframe-config-signaling-01
(work in progress), November 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses Authors' Addresses
Ulas C. Kozat Ulas C. Kozat
DoCoMo USA Labs DoCoMo USA Labs
3240 Hillview Avenue 3240 Hillview Avenue
Palo Alto, CA 94304-1201 Palo Alto, CA 94304-1201
skipping to change at page 13, line 4 skipping to change at line 514
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 Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: abegen@cisco.com Email: abegen@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 22 change blocks. 
34 lines changed or deleted 65 lines changed or added

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