draft-ietf-fecframe-pseudo-cdp-04.txt   draft-ietf-fecframe-pseudo-cdp-05.txt 
FEC Framework U. Kozat FEC Framework U. Kozat
Internet-Draft DoCoMo USA Labs Internet-Draft DoCoMo USA Labs
Intended status: Informational A. Begen Intended status: Informational A. Begen
Expires: December 22, 2012 Cisco Expires: April 20, 2013 Cisco
June 20, 2012 October 17, 2012
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-04 draft-ietf-fecframe-pseudo-cdp-05
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 FEC Framework and the Session Description Protocol (SDP) elements
defined for the framework. The purpose of the document is not to defined for the framework. The purpose of the document is not to
provide a full-pledged protocol, but to show how the defined provide a full-fledged 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 implement a
CDP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 22, 2012. This Internet-Draft will expire on April 20, 2013.
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 2, line 22 skipping to change at page 3, line 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 3 2. Definitions/Abbreviations . . . . . . . . . . . . . . . . . . 4
3. Construction of a Repair Flow from Multiple Source Flows . . . 3 3. Construction of a Repair Flow from Multiple Source Flows . . . 4
3.1. Example: Two Source Flows Protected by a Single Repair 3.1. Example: Two Source Flows Protected by a Single Repair
Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Reconstruction of Source Flows from Repair Flow(s) . . . . . . 9 4. Reconstruction of Source Flows from Repair Flow(s) . . . . . . 11
4.1. Example: Multiple Source Flows Protected by a Single 4.1. Example: Multiple Source Flows Protected by a Single
Repair Flow . . . . . . . . . . . . . . . . . . . . . . . 9 Repair Flow . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 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 Framework Configuration Information (described in [RFC6695]) on the
[I-D.ietf-fecframe-config-signaling]) on the other hand provides the other hand provides the signaling protocols that may be used as part
signaling protocols that may be used as part of CDP to communicate of CDP to communicate FEC Scheme-Specific Information from FEC sender
FEC Scheme-Specific Information from FEC sender to a single as well to a single as well as multiple FEC receivers. This document
as multiple FEC receivers. This document aims at providing a provides a guideline on how the mechanisms defined in [RFC6363] and
guideline on how the mechanisms defined in [RFC6363] and [RFC6364] [RFC6364] can be sufficiently used to design a CDP over a non-trivial
can be sufficiently used to design a CDP over a non-trivial scenario, scenario, namely protection of multiple source flows with one or more
namely protection of multiple source flows with one or more repair repair flows.
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,
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]. 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 (SB) by
multiplexing transport payloads from multiple flows (See Figure 1 and multiplexing transport payloads from multiple flows (See Figure 1 and
Figure 2). According to the FEC Framework, each source block is FEC- Figure 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 Explicit
skipping to change at page 6, line 12 skipping to change at page 7, line 12
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. The SDP description below states that the source flow defined 30000.
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. 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.
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
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 v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples s=FEC Framework Examples
t=0 0 t=0 0
a=group:FEC-FR S1 S2 R3 a=group:FEC-FR S1 S2 R3
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0 a=fec-source-flow: id=0
a=mid:S1 a=mid:S1
skipping to change at page 7, line 39 skipping to change at page 9, line 34
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 [I-D.ietf-fecframe-config-signaling]. In our example, described in [RFC6695]. In our example, we will consider the case
we will consider the case where the ordering is fixed and known both where the ordering is fixed and known both at the sender and the
at the sender and the receiver, but the payload lengths will be receiver, but the payload lengths will be variable from one source
variable from one source block to another. We assume that the block to another. We assume that the payload of a source flow with
payload of a source flow with an FID smaller than another flow's FID an FID smaller than another flow's FID precedes other payloads in a
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 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 8, line 39 skipping to change at page 10, line 32
+------------------------------------+ +------------------------------------+
| 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 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 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
skipping to change at page 9, line 21 skipping to change at page 11, line 15
+------------------------------------+ +------------------------------------+
| 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 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
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
received at {233.252.0.3,30000}. The CDP can map these tuples to the 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 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
skipping to change at page 10, line 29 skipping to change at page 12, line 28
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]. There are no additional security considerations refer to [RFC6363]. For the security considerations related to the
that apply to this document. SDP elements in the FEC Framework, refer to [RFC6364]. There are no
additional security considerations that apply to this document.
6. IANA Considerations 6. IANA Considerations
There are no IANA related issues considered in this document. There are no IANA related issues considered in this document.
7. Acknowledgments 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 8. 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.
[I-D.ietf-fecframe-config-signaling] [RFC6695] Asati, R., "Methods to Convey Forward Error Correction
Asati, R., "Methods to convey FEC Framework Configuration (FEC) Framework Configuration Information", RFC 6695,
Information", draft-ietf-fecframe-config-signaling-09 August 2012.
(work in progress), June 2012.
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
USA USA
Phone: +1 650 496 4739 Phone: +1 650 496 4739
 End of changes. 17 change blocks. 
47 lines changed or deleted 52 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/