PCEP Procedures and Extension for VLAN-based Traffic Forwarding
draft-wang-pce-vlan-based-traffic-forwarding-09
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yue Wang , Aijun Wang , Boris Khasanov , Fengwei Qin , Huaimo Chen , Chun Zhu | ||
| Last updated | 2024-04-09 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-pce-vlan-based-traffic-forwarding-09
Internet Engineering Task Force (IETF) M. Watson
Request for Comments: 6363 Netflix, Inc.
Category: Standards Track A. Begen
ISSN: 2070-1721 Cisco
V. Roca
INRIA
October 2011
Forward Error Correction (FEC) Framework
Abstract
This document describes a framework for using Forward Error
Correction (FEC) codes with applications in public and private IP
networks to provide protection against packet loss. The framework
supports applying FEC to arbitrary packet flows over unreliable
transport and is primarily intended for real-time, or streaming,
media. This framework can be used to define Content Delivery
Protocols that provide FEC for streaming media delivery or other
packet flows. Content Delivery Protocols defined using this
framework can support any FEC scheme (and associated FEC codes) that
is compliant with various requirements defined in this document.
Thus, Content Delivery Protocols can be defined that are not specific
to a particular FEC scheme, and FEC schemes can be defined that are
not specific to a particular Content Delivery Protocol.
Status of This Memo
This is an Internet Standards Track document.
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). Further information on
Internet Standards is available in 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/rfc6363.
Watson, et al. Standards Track [Page 1]
RFC 6363 FEC Framework October 2011
Copyright Notice
Copyright (c) 2011 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.
Watson, et al. Standards Track [Page 2]
RFC 6363 FEC Framework October 2011
Table of Contents
1. Introduction ....................................................3
2. Definitions and Abbreviations ...................................5
3. Architecture Overview ...........................................7
4. Procedural Overview ............................................11
4.1. General ...................................................11
4.2. Sender Operation ..........................................13
4.3. Receiver Operation ........................................15
5. Protocol Specification .........................................19
5.1. General ...................................................19
5.2. Structure of the Source Block .............................19
5.3. Packet Format for FEC Source Packets ......................19
5.3.1. Generic Explicit Source FEC Payload ID .............21
5.4. Packet Format for FEC Repair Packets ......................21
5.4.1. Packet Format for FEC Repair Packets over RTP ......22
5.5. FEC Framework Configuration Information ...................22
5.6. FEC Scheme Requirements ...................................24
6. Feedback .......................................................26
7. Transport Protocols ............................................27
8. Congestion Control .............................................27
8.1. Motivation ................................................27
8.2. Normative Requirements ....................................29
9. Security Considerations ........................................29
9.1. Problem Statement .........................................29
9.2. Attacks against the Data Flows ............................31
9.2.1. Access to Confidential Content .....................31
9.2.2. Content Corruption .................................32
9.3. Attacks against the FEC Parameters ........................33
9.4. When Several Source Flows Are to Be Protected Together ....33
9.5. Baseline Secure FEC Framework Operation ...................34
10. Operations and Management Considerations ......................35
10.1. What Are the Key Aspects to Consider? ....................35
10.2. Operational and Management Recommendations ...............36
11. IANA Considerations ...........................................39
12. Acknowledgments ...............................................39
13. References ....................................................40
13.1. Normative References .....................................40
13.2. Informative References ...................................40
1. Introduction
Many applications have a requirement to transport a continuous stream
of packetized data from a source (sender) to one or more destinations
(receivers) over networks that do not provide guaranteed packet
delivery. Primary examples are real-time, or streaming, media
applications such as broadcast, multicast, or on-demand forms of
audio, video, or multimedia.
Watson, et al. Standards Track [Page 3]
RFC 6363 FEC Framework October 2011
Forward Error Correction (FEC) is a well-known technique for
improving the reliability of packet transmission over networks that
do not provide guaranteed packet delivery, especially in multicast
and broadcast applications. The FEC Building Block, defined in
[RFC5052], provides a framework for the definition of Content
Delivery Protocols (CDPs) for object delivery (including, primarily,
file delivery) that make use of separately defined FEC schemes. Any
CDP defined according to the requirements of the FEC Building Block
can then easily be used with any FEC scheme that is also defined
according to the requirements of the FEC Building Block.
Note that the term "Forward Erasure Correction" is sometimes used,
erasures being a type of error in which data is lost and this loss
can be detected, rather than being received in corrupted form. The
focus of this document is strictly on erasures, and the term "Forward
Error Correction" is more widely used.
This document defines a framework for the definition of CDPs that
provide for FEC protection for arbitrary packet flows over unreliable
transports such as UDP. As such, this document complements the FEC
Building Block of [RFC5052], by providing for the case of arbitrary
packet flows over unreliable transport, the same kind of framework as
that document provides for object delivery. This document does not
define a complete CDP; rather, it defines only those aspects that are
expected to be common to all CDPs based on this framework.
This framework does not define how the flows to be protected are
determined, nor does it define how the details of the protected flows
and the FEC streams that protect them are communicated from sender to
receiver. It is expected that any complete CDP specification that
makes use of this framework will address these signaling
requirements. However, this document does specify the information
that is required by the FEC Framework at the sender and receiver,
e.g., details of the flows to be FEC protected, the flow(s) that will
carry the FEC protection data, and an opaque container for
FEC-Scheme-Specific Information.
FEC schemes designed for use with this framework must fulfill a
number of requirements defined in this document. These requirements
are different from those defined in [RFC5052] for FEC schemes for
object delivery. However, there is a great deal of commonality, and
FEC schemes defined for object delivery may be easily adapted for use
with the framework defined in this document.
Watson, et al. Standards Track [Page 4]
RFC 6363 FEC Framework October 2011
gt; is as per [RFC8231] and the LSP and SRP object are
also defined in [RFC8231].
<BPI> and <PPA> are as per
[draft-ietf-pce-pcep-extension-native-ip-09]
The error handling for missing LSP or CCI object is as per [RFC9050].
Further only one of BPI, PPA or one type of CCI objects MUST be
present. If none of them are present, the receiving PCE MUST send a
PCErr message with Error-type=6 (Mandatory Object missing) and Error-
value=TBD4 ( VLAN-based forwarding object missing). If there are
more than one of BPI, PPA or more than one type of CCI objects, the
receiving PCC MUST send a PCErr message with Error-type=19(Invalid
Operation) and Error-value=TBD5(Only one of BPI, PPA or one type of
the CCI objects for VLAN can be included in this message).
6. VSP Operations
Based on [RFC8281] and [RFC9050], in order to set up a PCE-initiated
VSP based on the PCECC mechanism, a PCE needs to send a PCInitiate
message with the PST set to TBD1 in SRP for the PCECC to the ingress
PCC.
The VLAN-forwarding instructions from the PCECC needs to be sent
after the initial PCInitiate and PCRpt message exchange with the
ingress PCC. On receipt of a PCInitiate message for the PCECC VSP,
Wang, et al. Expires 11 October 2024 [Page 7]
Internet-Draft pce April 2024
the PCC responds with a PCRpt message with the status set to 'Going-
up', carrying the assigned PLSP-ID and set the D(Delegate) flag and
C(Create) flag(see Figure 1).
After that, the PCE needs to send a PCInitiate message to each node
along the path to download the VLAN instructions. The new CCI for
the VLAN operations in PCEP are sent via the PCInitiate message by
defining a new PCEP object for CCI operations. The fields in the
LSP-IDENTIFIERS TLV are described for the RSVP-signaled LSPs but are
applicable to the PCECC VSP as well. So the LSP object is included
in the PCInitiate message can still be used to identify the PCECC VSP
for this instruction and the process is the same.
When the PCE receives this PCRpt message with the PLSP-ID, it assigns
VLANs along the path and sets up the path by sending a PCInitiate
message to each node along the path of the VSP, as per the PCECC
technique. The ingress PCC would receive one VLAN forwarding CCI
Object which contains VLAN on the logical subinterface and the Peer
IP address. The transit PCC would receive two VLAN crossing CCI
Objects with the O bit set for the out-VLAN on the egress
subinterface and the O bit unset for the in-VLAN on the ingress
subinterface. Similar with the transit PCC, the egress PCC would
receive two VLAN crossing CCI Objects but the out-VLAN on the egress
subinterface is set to 0. Once the VLAN operations are completed,
the PCE MUST send a PCUpd message to the ingress PCC.
Wang, et al. Expires 11 October 2024 [Page 8]
Internet-Draft pce April 2024
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1------| PCECC VSP
|PCC +--------+ |----PCRpt,PLSP-ID=2,D=1,C=1---------->| Initiate
|egress | | | (GOING-UP) | PCECC VSP
+--------+ | | |
| | | |
|<-------PCInitiate,VLAN-CROSSING-CC-ID=X1,X2--------| VLAN
| | PLSP-ID=2,IN-VLAN=N1,OUT-VLAN=0 | download
| | | | CCI
|--------PCRpt,VLAN-CROSSING-CC-ID=X1,X2------------>|
| |PLSP-ID=2,IN-VLAN=N1,OUT-VLAN=0 |
| | | |
| |<---PCInitiate,VLAN-CROSSING-CC-ID=Y1,Y2--->| VLAN
| | |PLSP-ID=2,IN-VLAN=N2,OUT-VLAN=N1 | download
| | | | CCI
| |-------PCRpt,VLAN-CROSSING-CC-ID=Y1,Y2----->|
| | |PLSP-ID=2,IN-VLAN=N2,OUT-VLAN=N1 |
| | | |
| | |<--PCInitiate,VLAN-FORWARDING-CC-ID=Z-| VLAN
| | | PLSP-ID=2,VLAN=N2 | download
| | | | CCI
| | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->|
| | | PLSP-ID=2,VLAN=N2 |
| | | |
| | |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC VSP
| | | (UP) | Update
| | |----PCRpt,PLSP-ID=2,D=1,C=1---------->|
| | | (UP) |
Figure 1: PCE-Initiated PCECC VSP
In order to delete an LSP based on the PCECC, the PCE sends CCI and
SRP object with the R bit set to 1 via a PCInitiate message to each
node along the path of the VSP to clean up the label-forwarding
instruction.
Wang, et al. Expires 11 October 2024 [Page 9]
Internet-Draft pce April 2024
As per [RFC9050], the PCECC VSP also follows the same make-before-
break principles. As shown in the figure 2, new path for VSP
triggers the new CCI Distribution process. The PCECC firstly updates
the new VLAN instructions and informs each node along the new path
through the new VLAN crossing CCI Objects and VLAN forwarding CCI
Objects to download the new VSP. The PCUpd message then triggers the
traffic switch on the updated path. On receipt of the PCRpt message
corresponding to the PCUpd message, the PCE does the cleanup
operation for the former VSP,which is the same as the LSP update
process.
+-------+ +-------+
|PCC | | PCE |
|ingress| +-------+
+------| | |
| PCC +-------+ |
| transit| | |
+------| | | |
|PCC +--------+ | |
|egress | | | |
+--------+ | | |
| | | |
|<----- PCInitiate,VLAN-CROSSING-CC-ID=NEW-X1,X2----| New Path
| | PLSP-ID=1,IN-VLAN=NEW-N1,OUT-VLAN=0 | for VSP
| | | | triggers
|--------PCRpt,VLAN-CROSSING-CC-ID=NEW-X1,X2------->| new CCI
| | PLSP-ID=1,IN-VLAN=NEW-N1,OUT-VLAN=0 |
| | | |
| |<----------PCInitiate,PLSP-ID=1------------|
| | |VLAN-CROSSING-CC-ID=NEW-Y1,NEW-Y2 | Label
| | | IN-VLAN=NEW-N2,OUT-VLAN=NEW-N1 | download
| | | | CCI
| |--------------PCRpt,PLSP-ID=1------------->|
| | |VLAN-CROSSING-CC-ID=NEW-Y1,NEW-Y2 |
| | | IN-VLAN=NEW-N2,OUT-VLAN=NEW-N1 |
| | | |
| | |<--------PCInitiate,PLSP-ID=1--------| Label
| | | VLAN-FORWARDING-CC-ID=NEW-Z | download
| | | VLAN=NEW-N2 | CCI
| | | |
| | |----------PCRpt,PLSP-ID=1----------->|
| | | LAN-FORWARDING-CC-ID=NEW-Z |
| | | VLAN=NEW-N2 |
| | | |
| | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC
| | | (SRP=S) | VSP Update
| | | |
| | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| Trigger
Wang, et al. Expires 11 October 2024 [Page 10]
Internet-Draft pce April 2024
| | | (SRP=S) | Delete
| | | | former CCI
| | | |
|<--------------PCInitiate, PLSP-ID=1---------------| Label
| | |VLAN-CROSSING-CC-ID=X1,X2,R=1 | cleanup
|----------------PCRpt,PLSP-ID=1------------------->| CCI
| | |VLAN-CROSSING-CC-ID=X1,X2,R=1 |
| | | |
| |<------------PCInitiate,PLSP-ID=1----------| Label
| | |VLAN-CROSSING-CC-ID=Y1,Y2,R=1 | cleanup
| |---------------PCRpt,PLSP-ID=1------------>| CCI
| | |VLAN-CROSSING-CC-ID=Y1,Y2,R=1 |
| | | |
| | |<--------PCInitiate,PLSP-ID=1--------| Label
| | |VLAN-FORWARDING-CC-ID=Z,R=1 | cleanup
| | |---------PCRpt,PLSP-ID=1------------>| CCI
| | |VLAN-FORWARDING-CC-ID=Z,R=1 |
Figure 2: PCECC VSP Update
7. VLAN-based traffic forwarding Procedures
The target deployment environment of VLAN based traffic forwarding
mechanism is for both Native IPv4 and IPv6. In such scenarios, the
BGP is used for the prefix distribution among underlying
devices(PCCs), no MPLS is involved.
In order to set up the VLAN-based traffic forwarding paths for
different applications in native IP network, multiple BGP sessions
should be deployed between the ingress PCC and egress PCC at the edge
of the network respectively.
Based on the business requirements, the PCE calculates the explicit
route and sends the route information to the PCCs through PCInitiate
messages. When the PCInitiate message is received, the packet to be
guaranteed will be labeled with corresponding VLAN tag, that is done
by the ingress PCC. The labeled packet will be further sent to the
PCC's specific subinterface identified by the VLAN tag and then be
forwarded. Similarly, after receive of the PCInitiate message, the
packet will be re-labeled with new VLAN tag and then be forwarded by
the transit PCC and the egress PCC. The mechanism of allocating and
managing VLAN ID by PCC is as per
[I-D.wang-vlan-based-traffic-forwarding].
Wang, et al. Expires 11 October 2024 [Page 11]
Internet-Draft pce April 2024
The whole procedures mainly focused on the end-to-end traffic
assurance for key applications so that it can ensure the adequacy of
VLAN quantity. During the packet forwarding process, the packet can
be encapsulated with reserved multicast MAC addresses(e.g.
0180:C200:0014 for ISIS level 1, 0180:C200:0015 for ISIS level 2)
thus does not need to be changed hop by hop by each PCC.
7.1. Multiple BGP Session Establishment Procedures
As described in section 4, multiple BGP sessions should be deployed
between the ingress device and egress device at the edge of the
network respectively in order to carry information of different
applications. As per [I-D.ietf-pce-pcep-extension-native-ip], the
PCE should send the BPI (BGP Peer Info) Object to the ingress and
egress device with the indicated Peer AS and Local/Peer IP address.
The Ingress and egress devices will receive multiple BPI objects to
establish sessions with different next hop. The specific process is
as follows:
+----------------------+
+---------+- PCE + --------+
| +----------^-----------+ |
| | | | |
| +--+ +--+ +--+ |
|------- +R2+ ------+R3+-------+R4+ --------
| +--+ +--+ +--+ |
| |
+--+ +--+ +--+
+R1+----------------+R5+----------------+R6+
+--+ +--+ +--+
| |
|<------------- BGP Session A ------------>|
|<------------- BGP Session B ------------>|
|<------------- BGP Session C ------------>|
Figure 3: BGP Session Establishment Procedures
7.2. BGP Prefix Advertisement Procedures
The detail procedures for BGP prefix advertisement procedures is
introduced in [I-D.ietf-pce-pcep-extension-native-ip], using
PCInitiate and PCRpt message pair.
The BGP prefix for different BGP sessions should be sent to the
ingress and egress device respectively. The end-to-end traffic for
key application can be identified based on these BGP prefix
informations and be further assured. As per
[I-D.ietf-pce-pcep-extension-native-ip], the PPA(Peer Prefix
Wang, et al. Expires 11 October 2024 [Page 12]
Internet-Draft pce April 2024
Association) object with list of prefix subobjects and the peer
address will be sent through the PCInitiate and PCRpt message pair.
Through BGP protocol, the ingress device can learn different BGP
prefix of the egress device based on the different sessions.
7.3. VLAN mapping info Advertisement Procedures
After the BGP prefix for different BGP session are successfully
advertised, information of different applications should be forwarded
to different VLAN-based traffic forwarding paths. In order to set up
a VLAN-based traffic forwarding path, the PCE should send the VLAN
forwarding CCI Object with the VLAN-ID included to the ingress PCC
and the VLAN crossing CCI Object to the transit PCC and egress PCC.
7.3.1. VLAN-Based forwarding info Advertisement Procedures
The detail procedures for VLAN-Based forwarding info advertisement
contained in the VLAN forwarding CCI Object are shown below, using
PCInitiate and PCRpt message pair.
The VLAN forwarding CCI Object should be sent through the PCInitiate
and PCRpt message pair. After the PCC receives the CCI object (with
the R bit set to 0 in SRP object) in PCInitiate message, the PCC's
subinterface will set up the specific VLAN based on the VLAN
forwarding CCI object, source and destination BGP prefix learnt
before. When the ingress PCC receives a packet, based on the source
and destination IP, the packet that needs to be guaranteed will be
matched and then be labeled with corresponding VLAN tag. After that,
The labeled packet will be further forwarded to the specific
subinterface as per [I-D.wang-vlan-based-traffic-forwarding].
When PCC receives the VLAN forwarding CCI Object with the R bit set
to 1 in SRP object in PCInitiate message, the PCC should withdraw the
VLAN-Based forwarding info advertisement to the peer that indicated
by this object.
On receipt of a PCInitiate message for the PCECC VSP, the PCC should
report the result via the PCRpt messages, with the corresponding SRP
and CCI object included.
Wang, et al. Expires 11 October 2024 [Page 13]
Internet-Draft pce April 2024
+----------------------+
+---------+ PCE + --------+
| +----------^-----------+ |
| | | | |
M1&M1-R | | | |
| | | | |
| | | | |
| +--+ +--+ +--+ |
|------- +R2+ ------+R3+-------+R4+ --------
| +--+ +--+ +--+ |
| |
+--+ +--+ +--+
+R1+----------------+R5+----------------+R6+
+--+ +--+ +--+
Figure 4: VLAN-Based forwarding info Advertisement
Procedures for Ingress PCC
The message number, message peers, message types and message key
parameters in the above figures are shown in the table below:
Table 1: Message Information
+-------------------------------------------------------------+
| No.| Peers| Type | Message Key Parameters |
+-------------------------------------------------------------+
|M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) |
|M1-R| |PCRpt |VLAN Forwarding CCI Object |
| | | |(Peer_IP=R6_A,Interface_Address=INF1, |
| | | |VLAN_ID=VLAN_R1_R2) |
+-------------------------------------------------------------+
7.3.2. VLAN-Based crossing info Advertisement Procedures
The detail procedures for VLAN-Based crossing info advertisement
contained in the VLAN crossing CCI Object are shown below, using
PCInitiate and PCRpt message pair.
Wang, et al. Expires 11 October 2024 [Page 14]
Internet-Draft pce April 2024
The PCC would receive VLAN crossing CCI Objects with the in-VLAN CCI
without the O bit set and the out-VLAN CCI with the O bit set. The
in-VLAN tag and an out-VLAN tag in the CCI Objects specifies a new
VLAN forwarding path. After the process of VLAN-Based forwarding
info advertisement mentioned above, the PCC's subinterface will set
up the specific VLAN based on the VLAN crossing CCI Object(with the R
bit set to 0 in SRP object) contained in the PCInitiate message.
When the transit PCC receives a data packet that has been labeled
with VLAN by ingress PCC before, based on matching process of the
VLAN tag, the in-VLAN tag of this data packet will be replaced by a
new out-VLAN tag of the current transit PCC as per
[I-D.wang-vlan-based-traffic-forwarding]. The packet with the new
VLAN tag will be further forwarded to the next hop.
For the egress PCC, the out-VLAN tag should be 0 which indicates it
is the last hop of the transmission. So the egress PCC will directly
remove the in-VLAN tag of the packet and the packet will be
forwarded.
When PCC receives the VLAN crossing CCI Object with the R bit set to
1 in SRP object in PCInitiate message, the PCC should withdraw the
VLAN-Based crossing info advertisement to the peer that indicated by
this object.
On receipt of a PCInitiate message for the PCECC VSP, the PCC should
report the result via the PCRpt messages, with the corresponding SRP
and CCI object included.
When the out-VLAN tag conflicts with a pre-defined VLAN tag or the
PCC can not set up a VLAN forwarding path with the out-VLAN tag, an
error (Error-type=TBD6, VLAN-based forwarding failure, Error-
value=TBD7, VLAN crossing CCI Object peer info mismatch) should be
reported via the PCRpt message.
Wang, et al. Expires 11 October 2024 [Page 15]
Internet-Draft pce April 2024
+----------------------+
+---------+ PCE + --------+
| +----------^-----------+ |
| | | | |
| M1&M1-R M2&M2-R M3&M3-R M4&M4-R
| | | | |
| +--+ +--+ +--+ |
|------- +R2+ ------+R3+-------+R4+ -------|
| +--+ +--+ +--+ |
| |
+--+ +--+ +--+
+R1+----------------+R5+----------------+R6+
+--+ +--+ +--+
Figure 5: VLAN-Based crossing info Advertisement Procedures
for transit PCC and egress PCC
The message number, message peers, message type and message key
parameters in the above figures are shown in below table:
Table 2: Message Information
+--------------------------------------------------------------------------+
| No.| Peers| Type | Message Key Parameters |
+--------------------------------------------------------------------------+
|M1 |PCE/R2|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) |
|M1-R| |PCRpt |VLAN crossing CCI Object(IN) |
| | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R1_R2) |
| | | |VLAN crossing CCI Object(OUT) |
| | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=VLAN_R2_R3)|
+--------------------------------------------------------------------------+
|M2 |PCE/R3|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) |
|M2-R| |PCRpt |VLAN crossing CCI Object(IN) |
| | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R2_R3) |
| | | |VLAN crossing CCI Object(OUT) |
| | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=VLAN_R3_R4)|
+--------------------------------------------------------------------------+
|M3 |PCE/R4|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) |
|M3-R| |PCRpt |VLAN crossing CCI Object(IN) |
| | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R3_R4) |
| | | |VLAN crossing CCI Object(OUT) |
| | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=VLAN_R4_R6)|
+--------------------------------------------------------------------------+
|M4 |PCE/R6|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) |
|M4-R| |PCRpt |VLAN crossing CCI Object(IN) |
| | | |(O=0,Interface_Address=INF1,IN_VLAN_ID=VLAN_R4_R6) |
| | | |VLAN crossing CCI Object(OUT) |
| | | |(O=1,Interface_Address=INF2,OUT_VLAN_ID=0) |
+--------------------------------------------------------------------------+
Wang, et al. Expires 11 October 2024 [Page 16]
Internet-Draft pce April 2024
Since RTP [RFC3550] is (often) used over UDP, this framework can be
applied to RTP flows as well. FEC repair packets may be sent
directly over UDP or RTP. The latter approach has the advantage that
RTP instrumentation, based on the RTP Control Protocol (RTCP), can be
used for the repair flow. Additionally, the post-repair RTCP
extended reports [RFC5725] may be used to obtain information about
the loss rate after FEC recovery.
The use of RTP for repair flows is defined for each FEC scheme by
defining an RTP payload format for that particular FEC scheme
(possibly in the same document).
2. Definitions and Abbreviations
Application Data Unit (ADU): The unit of source data provided as
payload to the transport layer.
ADU Flow: A sequence of ADUs associated with a transport-layer flow
identifier (such as the standard 5-tuple {source IP address,
source port, destination IP address, destination port, transport
protocol}).
AL-FEC: Application-layer Forward Error Correction.
Application Protocol: Control protocol used to establish and control
the source flow being protected, e.g., the Real-Time Streaming
Protocol (RTSP).
Content Delivery Protocol (CDP): A complete application protocol
specification that, through the use of the framework defined in
this document, is able to make use of FEC schemes to provide FEC
capabilities.
FEC Code: An algorithm for encoding data such that the encoded data
flow is resilient to data loss. Note that, in general, FEC codes
may also be used to make a data flow resilient to corruption, but
that is not considered in this document.
FEC Framework: A protocol framework for the definition of Content
Delivery Protocols using FEC, such as the framework defined in
this document.
FEC Framework Configuration Information: Information that controls
the operation of the FEC Framework.
FEC Payload ID: Information that identifies the contents of a packet
with respect to the FEC scheme.
Watson, et al. Standards Track [Page 5]
RFC 6363 FEC Framework October 2011
FEC Repair Packet: At a sender (respectively, at a receiver), a
payload submitted to (respectively, received from) the transport
protocol containing one or more repair symbols along with a Repair
FEC Payload ID and possibly an RTP header.
FEC Scheme: A specification that defines the additional protocol
aspects required to use a particular FEC code with the FEC
Framework.
FEC Source Packet: At a sender (respectively, at a receiver), a
payload submitted to (respectively, received from) the transport
protocol containing an ADU along with an optional Explicit Source
FEC Payload ID.
Protection Amount: The relative increase in data sent due to the use
of FEC.
Repair Flow: The packet flow carrying FEC data.
Repair FEC Payload ID: A FEC Payload ID specifically for use with
repair packets.
Source Flow: The packet flow to which FEC protection is to be
applied. A source flow consists of ADUs.
Source FEC Payload ID: A FEC Payload ID specifically for use with
source packets.
Source Protocol: A protocol used for the source flow being protected,
e.g., RTP.
Transport Protocol: The protocol used for the transport of the source
and repair flows, e.g., UDP and the Datagram Congestion Control
Protocol (DCCP).
The following definitions are aligned with [RFC5052]:
Code Rate: The ratio between the number of source symbols and the
number of encoding symbols. By definition, the code rate is such
that 0 < code rate <= 1. A code rate close to 1 indicates that a
small number of repair symbols have been produced during the
encoding process.
Encoding Symbol: Unit of data generated by the encoding process.
With systematic codes, source symbols are part of the encoding
symbols.
Watson, et al. Standards Track [Page 6]
RFC 6363 FEC Framework October 2011
Packet Erasure Channel: A communication path where packets are either
dropped (e.g., by a congested router, or because the number of
transmission errors exceeds the correction capabilities of the
physical-layer codes) or received. When a packet is received, it
is assumed that this packet is not corrupted.
Repair Symbol: Encoding symbol that is not a source symbol.
Source Block: Group of ADUs that are to be FEC protected as a single
block.
Source Symbol: Unit of data used during the encoding process.
Systematic Code: FEC code in which the source symbols are part of the
encoding symbols.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Architecture Overview
The FEC Framework is described in terms of an additional layer
between the transport layer (e.g., UDP or DCCP) and protocols running
over this transport layer. As such, the data path interface between
the FEC Framework and both underlying and overlying layers can be
thought of as being the same as the standard interface to the
transport layer; i.e., the data exchanged consists of datagram
payloads each associated with a single ADU flow identified by the
standard 5-tuple {source IP address, source port, destination IP
address, destination port, transport protocol}. In the case that RTP
is used for the repair flows, the source and repair data can be
multiplexed using RTP onto a single UDP flow and needs to be
consequently demultiplexed at the receiver. There are various ways
in which this multiplexing can be done (for example, as described in
[RFC4588]).
It is important to understand that the main purpose of the FEC
Framework architecture is to allocate functional responsibilities to
separately documented components in such a way that specific
instances of the components can be combined in different ways to
describe different protocols.
The FEC Framework makes use of a FEC scheme, in a similar sense to
that defined in [RFC5052], and uses the terminology of that document.
The FEC scheme defines the FEC encoding and decoding, and it defines
the protocol fields and procedures used to identify packet payload
data in the context of the FEC scheme. The interface between the FEC
Watson, et al. Standards Track [Page 7]
RFC 6363 FEC Framework October 2011
Framework and a FEC scheme, which is described in this document, is a
logical one that exists for specification purposes only. At an
encoder, the FEC Framework passes ADUs to the FEC scheme for FEC
encoding. The FEC scheme returns repair symbols with their
associated Repair FEC Payload IDs and, in some cases, Source FEC
Payload IDs, depending on the FEC scheme. At a decoder, the FEC
Framework passes transport packet payloads (source and repair) to the
FEC scheme, and the FEC scheme returns additional recovered source
packet payloads.
This document defines certain FEC Framework Configuration Information
that MUST be available to both sender and receiver(s). For example,
this information includes the specification of the ADU flows that are
to be FEC protected, specification of the ADU flow(s) that will carry
the FEC protection (repair) data, and the relationship(s) between
these source and repair flows (i.e., which source flow(s) are
protected by repair flow(s)). The FEC Framework Configuration
Information also includes information fields that are specific to the
FEC scheme. This information is analogous to the FEC Object
Transmission Information defined in [RFC5052].
The FEC Framework does not define how the FEC Framework Configuration
Information for the stream is communicated from sender to receiver.
This has to be defined by any CDP specification, as described in the
following sections.
In this architecture, we assume that the interface to the transport
layer supports the concepts of data units (referred to here as
Application Data Units (ADUs)) to be transported and identification
of ADU flows on which those data units are transported. Since this
is an interface internal to the architecture, we do not specify this
interface explicitly. We do require that ADU flows that are distinct
from the transport layer point of view (for example, distinct UDP
flows as identified by the UDP source/destination addresses/ports)
are also distinct on the interface between the transport layer and
the FEC Framework.
As noted above, RTP flows are a specific example of ADU flows that
might be protected by the FEC Framework. From the FEC Framework
point of view, RTP source flows are ADU flows like any other, with
the RTP header included within the ADU.
Depending on the FEC scheme, RTP can also be used as a transport for
repair packet flows. In this case, a FEC scheme has to define an RTP
payload format for the repair data.
Watson, et al. Standards Track [Page 8]
RFC 6363 FEC Framework October 2011
The architecture outlined above is illustrated in Figure 1. In this
architecture, two (optional) RTP instances are shown, for the source
and repair data, respectively. This is because the use of RTP for
the source data is separate from, and independent of, the use of RTP
for the repair data. The appearance of two RTP instances is more
natural when one considers that in many FEC codes, the repair payload
contains repair data calculated across the RTP headers of the source
packets. Thus, a repair packet carried over RTP starts with an RTP
header of its own, which is followed (after the Repair Payload ID) by
repair data containing bytes that protect the source RTP headers (as
well as repair data for the source RTP payloads).
Watson, et al. Standards Track [Page 9]
RFC 6363 FEC Framework October 2011
+--------------------------------------------+
| Application |
+--------------------------------------------+
|
|
|
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ |
| Application Layer |
| +--------------------------------------------+ |
| |
| + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP (Optional) | |
| | | |- Configuration/
+- -- -- -- -- -- -- -- -- -- -- -+ | Coordination
| | | |
| ADU flows |
| | v |
+--------------------------------------------+ +------------+
| | FEC Framework (This document) |<--->| FEC Scheme |
+--------------------------------------------+ +------------+
| | | |
Source | Repair |
| | | |
+-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
| | RTP Layer | | RTP Processing | | |
| (Optional) | +-- -- -- |- -- -+ |
| | +-- -- -- -- -- -- -- |--+ | |
| | RTP (De)multiplexing | |
| +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
|
| +--------------------------------------------+ |
| Transport Layer (e.g., UDP) |
| +--------------------------------------------+ |
|
| +--------------------------------------------+ |
| IP |
| +--------------------------------------------+ |
| Content Delivery Protocol |
+ - - - - - - - - - - - - - - - - - - - - - - - +
Figure 1: FEC Framework Architecture
Watson, et al. Standards Track [Page 10]
RFC 6363 FEC Framework October 2011
The content of the transport payload for repair packets is fully
defined by the FEC scheme. For a specific FEC scheme, a means MAY be
defined for repair data to be carried over RTP, in which case, the
repair packet payload format starts with the RTP header. This
corresponds to defining an RTP payload format for the specific FEC
scheme.
The use of RTP for repair packets is independent of the protocols
used for source packets: if RTP is used for source packets, repair
packets may or may not use RTP and vice versa (although it is
unlikely that there are useful scenarios where non-RTP source flows
are protected by RTP repair flows). FEC schemes are expected to
recover entire transport payloads for recovered source packets in all
cases. For example, if RTP is used for source flows, the FEC scheme
is expected to recover the entire UDP payload, including the RTP
header.
4. Procedural Overview
4.1. General
The mechanism defined in this document does not place any
restrictions on the ADUs that can be protected together, except that
the ADU be carried over a supported transport protocol (see
Section 7). The data can be from multiple source flows that are
protected jointly. The FEC Framework handles the source flows as a
sequence of source blocks each consisting of a set of ADUs, possibly
from multiple source flows that are to be protected together. For
example, each source block can be constructed from those ADUs related
to a particular segment in time of the flow.
At the sender, the FEC Framework passes the payloads for a given
block to the FEC scheme for FEC encoding. The FEC scheme performs
the FEC encoding operation and returns the following information:
o Optionally, FEC Payload IDs for each of the source payloads
(encoded according to a FEC-Scheme-Specific format).
o One or more FEC repair packet payloads.
o FEC Payload IDs for each of the repair packet payloads (encoded
according to a FEC-Scheme-Specific format).
Watson, et al. Standards Track [Page 11]
RFC 6363 FEC Framework October 2011
The FEC Framework then performs two operations. First, it appends
the Source FEC Payload IDs, if provided, to each of the ADUs, and
sends the resulting packets, known as "FEC source packets", to the
receiver. Second, it places the provided FEC repair packet payloads
and corresponding Repair FEC Payload IDs appropriately to construct
FEC repair packets and send them to the receiver.
This document does not define how the sender determines which ADUs
are included in which source blocks or the sending order and timing
of FEC source and repair packets. A specific CDP MAY define this
mapping, or it MAY be left as implementation dependent at the sender.
However, a CDP specification MUST define how a receiver determines a
minimum length of time that it needs to wait to receive FEC repair
packets for any given source block. FEC schemes MAY define
limitations on this mapping, such as maximum size of source blocks,
but they SHOULD NOT attempt to define specific mappings. The
sequence of operations at the sender is described in more detail in
Section 4.2.
At the receiver, original ADUs are recovered by the FEC Framework
directly from any FEC source packets received simply by removing the
Source FEC Payload ID, if present. The receiver also passes the
contents of the received ADUs, plus their FEC Payload IDs, to the FEC
scheme for possible decoding.
If any ADUs related to a given source block have been lost, then the
FEC scheme can perform FEC decoding to recover the missing ADUs
(assuming sufficient FEC source and repair packets related to that
source block have been received).
Note that the receiver might need to buffer received source packets
to allow time for the FEC repair packets to arrive and FEC decoding
to be performed before some or all of the received or recovered
packets are passed to the application. If such a buffer is not
provided, then the application has to be able to deal with the severe
re-ordering of packets that can occur. However, such buffering is
CDP- and/or implementation-specific and is not specified here. The
receiver operation is described in more detail in Section 4.3.
The FEC source packets MUST contain information that identifies the
source block and the position within the source block (in terms
specific to the FEC scheme) occupied by the ADU. This information is
known as the Source FEC Payload ID. The FEC scheme is responsible
for defining and interpreting this information. This information MAY
be encoded into a specific field within the FEC source packet format
defined in this specification, called the Explicit Source FEC Payload
ID field. The exact contents and format of the Explicit Source FEC
Payload ID field are defined by the FEC schemes. Alternatively, the
Watson, et al. Standards Track [Page 12]
RFC 6363 FEC Framework October 2011
FEC scheme MAY define how the Source FEC Payload ID is derived from
other fields within the source packets. This document defines the
way that the Explicit Source FEC Payload ID field is appended to
source packets to form FEC source packets.
The FEC repair packets MUST contain information that identifies the
source block and the relationship between the contained repair
payloads and the original source block. This is known as the Repair
FEC Payload ID. This information MUST be encoded into a specific
field, the Repair FEC Payload ID field, the contents and format of
which are defined by the FEC schemes.
The FEC scheme MAY use different FEC Payload ID field formats for
source and repair packets.
4.2. Sender Operation
It is assumed that the sender has constructed or received original
data packets for the session. These could be carrying any type of
data. The following operations, illustrated in Figure 2 for the case
of UDP repair flows and in Figure 3 for the case of RTP repair flows,
describe a possible way to generate compliant source and repair
flows:
1. ADUs are provided by the application.
2. A source block is constructed as specified in Section 5.2.
3. The source block is passed to the FEC scheme for FEC encoding.
The Source FEC Payload ID information of each source packet is
determined by the FEC scheme. If required by the FEC scheme, the
Source FEC Payload ID is encoded into the Explicit Source FEC
Payload ID field.
4. The FEC scheme performs FEC encoding, generating repair packet
payloads from a source block and a Repair FEC Payload ID field
for each repair payload.
5. The Explicit Source FEC Payload IDs (if used), Repair FEC Payload
IDs, and repair packet payloads are provided back from the FEC
scheme to the FEC Framework.
6. The FEC Framework constructs FEC source packets according to
Section 5.3, and FEC repair packets according to Section 5.4,
using the FEC Payload IDs and repair packet payloads provided by
the FEC scheme.
Watson, et al. Standards Track [Page 13]
RFC 6363 FEC Framework October 2011
7. The FEC source and repair packets are sent using normal
transport-layer procedures. The port(s) and multicast group(s)
to be used for FEC repair packets are defined in the FEC
Framework Configuration Information. The FEC source packets are
sent using the same ADU flow identification information as would
have been used for the original source packets if the FEC
Framework were not present (for example, in the UDP case, the UDP
source and destination addresses and ports on the IP datagram
carrying the source packet will be the same whether or not the
FEC Framework is applied).
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source and repair | | |
| packets |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs
| Repair symbols
|
|(7) FEC source and repair packets
v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 2: Sender Operation
Watson, et al. Standards Track [Page 14]
RFC 6363 FEC Framework October 2011
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source packets and| | |
| repair payloads |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| | Repair FEC Payload IDs
| | Repair symbols
| |
|(7) Source |(7') Repair payloads
| packets |
| |
| + -- -- -- -- -+
| | RTP |
| +-- -- -- -- --+
v v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 3: Sender Operation with RTP Repair Flows
4.3. Receiver Operation
The following describes a possible receiver algorithm, illustrated in
Figures 4 and 5 for the case of UDP and RTP repair flows,
respectively, when receiving a FEC source or repair packet:
1. FEC source packets and FEC repair packets are received and passed
to the FEC Framework. The type of packet (source or repair) and
the source flow to which it belongs (in the case of source
packets) are indicated by the ADU flow information, which
identifies the flow at the transport layer.
In the special case that RTP is used for repair packets, and
source and repair packets are multiplexed onto the same UDP flow,
then RTP demultiplexing is required to demultiplex source and
Watson, et al. Standards Track [Page 15]
RFC 6363 FEC Framework October 2011
repair flows. However, RTP processing is applied only to the
repair packets at this stage; source packets continue to be
handled as UDP payloads (i.e., including their RTP headers).
2. The FEC Framework extracts the Explicit Source FEC Payload ID
field (if present) from the source packets and the Repair FEC
Payload ID from the repair packets.
3. The Explicit Source FEC Payload IDs (if present), Repair FEC
Payload IDs, and FEC source and repair payloads are passed to the
FEC scheme.
4. The FEC scheme uses the received FEC Payload IDs (and derived FEC
Source Payload IDs in the case that the Explicit Source FEC
Payload ID field is not used) to group source and repair packets
into source blocks. If at least one source packet is missing
from a source block, and at least one repair packet has been
received for the same source block, then FEC decoding can be
performed in order to recover missing source payloads. The FEC
scheme determines whether source packets have been lost and
whether enough data for decoding of any or all of the missing
source payloads in the source block has been received.
5. The FEC scheme returns the ADUs to the FEC Framework in the form
of source blocks containing received and decoded ADUs and
indications of any ADUs that were missing and could not be
decoded.
6. The FEC Framework passes the received and recovered ADUs to the
application.
The description above defines functionality responsibilities but does
not imply a specific set of timing relationships. Source packets
that are correctly received and those that are reconstructed MAY be
delivered to the application out of order and in a different order
from the order of arrival at the receiver. Alternatively, buffering
and packet re-ordering MAY be applied to re-order received and
reconstructed source packets into the order they were placed into the
source block, if that is necessary according to the application.
Watson, et al. Standards Track [Page 16]
RFC 6363 FEC Framework October 2011
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ Repair FEC Payload IDs
| Source payloads
| Repair payloads
|
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 4: Receiver Operation
Watson, et al. Standards Track [Page 17]
RFC 6363 FEC Framework October 2011
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ ^ Repair FEC Payload IDs
| | Source payloads
| | Repair payloads
| |
|Source |Repair payloads
|packets |
| |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux | |
+-- -- -- -- -- -- -- -+
^
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 5: Receiver Operation with RTP Repair Flows
Note that the above procedure might result in a situation in which
not all ADUs are recovered.
Watson, et al. Standards Track [Page 18]
RFC 6363 FEC Framework October 2011
5. Protocol Specification
5.1. General
This section specifies the protocol elements for the FEC Framework.
Three components of the protocol are defined in this document and are
described in the following sections:
1. Construction of a source block from ADUs. The FEC code will be
applied to this source block to produce the repair payloads.
2. A format for packets containing source data.
3. A format for packets containing repair data.
The operation of the FEC Framework is governed by certain FEC
Framework Configuration Information, which is defined in this
section. A complete protocol specification that uses this framework
MUST specify the means to determine and communicate this information
between sender and receiver.
5.2. Structure of the Source Block
The FEC Framework and FEC scheme exchange ADUs in the form of source
blocks. A source block is generated by the FEC Framework from an
ordered sequence of ADUs. The allocation of ADUs to blocks is
dependent on the application. Note that some ADUs may not be
included in any block. Each source block provided to the FEC scheme
consists of an ordered sequence of ADUs where the following
information is provided for each ADU:
o A description of the source flow with which the ADU is associated.
o The ADU itself.
o The length of the ADU.
5.3. Packet Format for FEC Source Packets
The packet format for FEC source packets MUST be used to transport
the payload of an original source packet. As depicted in Figure 6,
it consists of the original packet, optionally followed by the
Explicit Source FEC Payload ID field. The FEC scheme determines
whether the Explicit Source FEC Payload ID field is required. This
determination is specific to each ADU flow.
Watson, et al. Standards Track [Page 19]
RFC 6363 FEC Framework October 2011
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Application Data Unit |
+------------------------------------+
| Explicit Source FEC Payload ID |
+------------------------------------+
Figure 6: Structure of the FEC Packet Format for FEC Source Packets
The FEC source packets MUST be sent using the same ADU flow as would
have been used for the original source packets if the FEC Framework
were not present. The transport payload of the FEC source packet
MUST consist of the ADU followed by the Explicit Source FEC Payload
ID field, if required.
The Explicit Source FEC Payload ID field contains information
required to associate the source packet with a source block and for
the operation of the FEC algorithm, and is defined by the FEC scheme.
The format of the Source FEC Payload ID field is defined by the FEC
scheme. In the case that the FEC scheme or CDP defines a means to
derive the Source FEC Payload ID from other information in the packet
(for example, a sequence number used by the application protocol),
then the Source FEC Payload ID field is not included in the packet.
In this case, the original source packet and FEC source packet are
identical.
In applications where avoidance of IP packet fragmentation is a goal,
CDPs SHOULD consider the Explicit Source FEC Payload ID size when
determining the size of ADUs that will be delivered using the FEC
Framework. This is because the addition of the Explicit Source FEC
Payload ID increases the packet length.
The Explicit Source FEC Payload ID is placed at the end of the
packet, so that in the case that Robust Header Compression (ROHC)
[RFC3095] or other header compression mechanisms are used, and in the
case that a ROHC profile is defined for the protocol carried within
the transport payload (for example, RTP), then ROHC will still be
applied for the FEC source packets. Applications that are used with
this framework need to consider that FEC schemes can add this
Explicit Source FEC Payload ID and thereby increase the packet size.
In many applications, support for FEC is added to a pre-existing
protocol, and in this case, use of the Explicit Source FEC Payload ID
can break backward compatibility, since source packets are modified.
Watson, et al. Standards Track [Page 20]
RFC 6363 FEC Framework October 2011
5.3.1. Generic Explicit Source FEC Payload ID
In order to apply FEC protection using multiple FEC schemes to a
single source flow, all schemes have to use the same Explicit Source
FEC Payload ID format. In order to enable this, it is RECOMMENDED
that FEC schemes support the Generic Explicit Source FEC Payload ID
format described below.
The Generic Explicit Source FEC Payload ID has a length of two octets
and consists of an unsigned packet sequence number in network-byte
order. The allocation of sequence numbers to packets is independent
of any FEC scheme and of the source block construction, except that
the use of this sequence number places a constraint on source block
construction. Source packets within a given source block MUST have
consecutive sequence numbers (where consecutive includes wrap-around
from the maximum value that can be represented in two octets (65535)
to 0). Sequence numbers SHOULD NOT be reused until all values in the
sequence number space have been used.
Note that if the original packets of the source flow are already
carrying a packet sequence number that is at least two bytes long,
there is no need to add the generic Explicit Source FEC Payload ID
and modify the packets.
5.4. Packet Format for FEC Repair Packets
The packet format for FEC repair packets is shown in Figure 7. The
transport payload consists of a Repair FEC Payload ID field followed
by repair data generated in the FEC encoding process.
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
Figure 7: Packet Format for FEC Repair Packets
The Repair FEC Payload ID field contains information required for the
operation of the FEC algorithm at the receiver. This information is
defined by the FEC scheme. The format of the Repair FEC Payload ID
field is defined by the FEC scheme.
Watson, et al. Standards Track [Page 21]
RFC 6363 FEC Framework October 2011
5.4.1. Packet Format for FEC Repair Packets over RTP
For FEC schemes that specify the use of RTP for repair packets, the
packet format for repair packets includes an RTP header as shown in
Figure 8.
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header (UDP) |
+------------------------------------+
| RTP Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
Figure 8: Packet Format for FEC Repair Packets over RTP
5.5. FEC Framework Configuration Information
The FEC Framework Configuration Information is information that the
FEC Framework needs in order to apply FEC protection to the ADU
flows. A complete CDP specification that uses the framework
specified here MUST include details of how this information is
derived and communicated between sender and receiver.
The FEC Framework Configuration Information includes identification
of the set of source flows. For example, in the case of UDP, each
source flow is uniquely identified by a tuple {source IP address,
source UDP port, destination IP address, destination UDP port}. In
some applications, some of these fields can contain wildcards, so
that the flow is identified by a subset of the fields. In
particular, in many applications the limited tuple {destination IP
address, destination UDP port} is sufficient.
A single instance of the FEC Framework provides FEC protection for
packets of the specified set of source flows, by means of one or more
packet flows consisting of repair packets. The FEC Framework
Configuration Information includes, for each instance of the FEC
Framework:
Watson, et al. Standards Track [Page 22]
RFC 6363 FEC Framework October 2011
1. Identification of the repair flows.
2. For each source flow protected by the repair flow(s):
A. Definition of the source flow.
B. An integer identifier for this flow definition (i.e., tuple).
This identifier MUST be unique among all source flows that
are protected by the same FEC repair flow. Integer
identifiers can be allocated starting from zero and
increasing by one for each flow. However, any random (but
still unique) allocation is also possible. A source flow
identifier need not be carried in source packets, since
source packets are directly associated with a flow by virtue
of their packet headers.
3. The FEC Encoding ID, identifying the FEC scheme.
4. The length of the Explicit Source FEC Payload ID (in octets).
5. Zero or more FEC-Scheme-Specific Information (FSSI) elements,
each consisting of a name and a value where the valid element
names and value ranges are defined by the FEC scheme.
Multiple instances of the FEC Framework, with separate and
independent FEC Framework Configuration Information, can be present
at a sender or receiver. A single instance of the FEC Framework
protects packets of the source flows identified in (2) above; i.e.,
all packets sent on those flows MUST be FEC source packets as defined
in Section 5.3. A single source flow can be protected by multiple
instances of the FEC Framework.
The integer flow identifier identified in (2B) above is a shorthand
to identify source flows between the FEC Framework and the FEC
scheme. The reason for defining this as an integer, and including it
in the FEC Framework Configuration Information, is so that the FEC
scheme at the sender and receiver can use it to identify the source
flow with which a recovered packet is associated. The integer flow
identifier can therefore take the place of the complete flow
description (e.g., UDP 4-tuple).
Whether and how this flow identifier is used is defined by the FEC
scheme. Since repair packets can provide protection for multiple
source flows, repair packets either would not carry the identifier at
all or can carry multiple identifiers. However, in any case, the
flow identifier associated with a particular source packet can be
recovered from the repair packets as part of a FEC decoding
operation.
Watson, et al. Standards Track [Page 23]
RFC 6363 FEC Framework October 2011
A single FEC repair flow provides repair packets for a single
instance of the FEC Framework. Other packets MUST NOT be sent within
this flow; i.e., all packets in the FEC repair flow MUST be FEC
repair packets as defined in Section 5.4 and MUST relate to the same
FEC Framework instance.
In the case that RTP is used for repair packets, the identification
of the repair packet flow can also include the RTP payload type to be
used for repair packets.
FSSI includes the information that is specific to the FEC scheme used
by the CDP. FSSI is used to communicate the information that cannot
be adequately represented otherwise and is essential for proper FEC
encoding and decoding operations. The motivation behind separating
the FSSI required only by the sender (which is carried in a Sender-
Side FEC-Scheme-Specific Information (SS-FSSI) container) from the
rest of the FSSI is to provide the receiver or the third-party
entities a means of controlling the FEC operations at the sender.
Any FSSI other than the one solely required by the sender MUST be
communicated via the FSSI container.
The variable-length SS-FSSI and FSSI containers transmit the
information in textual representation and contain zero or more
distinct elements, whose descriptions are provided by the fully
specified FEC schemes.
For the CDPs that choose the Session Description Protocol (SDP)
[RFC4566] for their multimedia sessions, the ABNF [RFC5234] syntax
for the SS-FSSI and FSSI containers is provided in Section 4.5 of
[RFC6364].
5.6. FEC Scheme Requirements
In order to be used with this framework, a FEC scheme MUST be capable
of processing data arranged into blocks of ADUs (source blocks).
A specification for a new FEC scheme MUST include the following:
1. The FEC Encoding ID value that uniquely identifies the FEC
scheme. This value MUST be registered with IANA, as described in
Section 11.
2. The type, semantics, and encoding format of the Repair FEC
Payload ID.
3. The name, type, semantics, and text value encoding rules for zero
or more FEC-Scheme-Specific Information elements.
Watson, et al. Standards Track [Page 24]
RFC 6363 FEC Framework October 2011
4. A full specification of the FEC code.
This specification MUST precisely define the valid FEC-Scheme-
Specific Information values, the valid FEC Payload ID values, and
the valid packet payload sizes (where packet payload refers to
the space within a packet dedicated to carrying encoding
symbols).
Furthermore, given a source block as defined in Section 5.2,
valid values of the FEC-Scheme-Specific Information, a valid
Repair FEC Payload ID value, and a valid packet payload size, the
specification MUST uniquely define the values of the encoding
symbols to be included in the repair packet payload of a packet
with the given Repair FEC Payload ID value.
A common and simple way to specify the FEC code to the required
level of detail is to provide a precise specification of an
encoding algorithm that -- given a source block, valid values of
the FEC-Scheme-Specific Information, a valid Repair FEC Payload
ID value, and a valid packet payload size as input -- produces
the exact value of the encoding symbols as output.
5. A description of practical encoding and decoding algorithms.
This description need not be to the same level of detail as for
the encoding above; however, it has to be sufficient to
demonstrate that encoding and decoding of the code are both
possible and practical.
FEC scheme specifications MAY additionally define the following:
Type, semantics, and encoding format of an Explicit Source FEC
Payload ID.
Whenever a FEC scheme specification defines an 'encoding format' for
an element, this has to be defined in terms of a sequence of bytes
that can be embedded within a protocol. The length of the encoding
format either MUST be fixed or it MUST be possible to derive the
length from examining the encoded bytes themselves. For example, the
initial bytes can include some kind of length indication.
Watson, et al. Standards Track [Page 25]
RFC 6363 FEC Framework October 2011
FEC scheme specifications SHOULD use the terminology defined in this
document and SHOULD follow the following format:
1. Introduction <Describe the use cases addressed by this FEC
scheme>
2. Formats and Codes
2.1. Source FEC Payload ID(s) <Either define the type and
format of the Explicit Source FEC Payload ID or define how
Source FEC Payload ID information is derived from source
packets>
2.2. Repair FEC Payload ID <Define the type and format of the
Repair FEC Payload ID>
2.3. FEC Framework Configuration Information &8. New PCEP Objects
The Central Control Instructions (CCI) Object is used by the PCE to
specify the forwarding instructions is defined in [RFC9050]. This
document defines two other CCI object-types for VLAN-based traffic
forwarding. All new PCEP objects are compliant with the PCEP object
format defined in [RFC5440].
8.1. VLAN forwarding CCI Object
The VLAN forwarding CCI Object is used to set up the specific VLAN
forwarding path including the logical subinterface that will be used
for traffic forwarding to the specific hop. Combined with this type
of CCI Object and the Peer Prefix Association object(PPA) defined in
[I-D.ietf-pce-pcep-extension-native-ip], the ingress PCC will
identify the traffic that needs to be protected. This object should
only be included and sent to the ingress PCC of the end2end path.
CCI Object-Class is 44.
CCI Object-Type is TBD8 for VLAN forwarding info in the native IP
network.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Interface Address TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Peer IP Address TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Additional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: VLAN Forwarding CCI Object
The fields in the CCI object are as follows:
Wang, et al. Expires 11 October 2024 [Page 17]
Internet-Draft pce April 2024
CC-ID: is as described in [RFC9050]. Following fields are defined
for CCI Object-Type TBD8.
Reserved1(16 bits): is set to zero while sending, ignored on receipt.
Flags(16 bits): is used to carry any additional information
pertaining to the CCI. Currently no flag bits are defined.
VLAN ID(12 bits):the ID of the VLAN forwarding path that the PCC will
set up on its logical subinterface in order to transfer the packet to
the specific hop.
Reserved2(20 bits): is set to zero while sending, ignored on receipt.
Interface Address TLV [RFC8779] MUST be included in this CCI Object-
Type TBD8 to specify the interface which will set up the vlan defined
in the VLAN Forwarding CCI Object.
The Peer IP Address TLV [RFC8779]MUST be included in this CCI Object-
Type TBD8 to identify the end to end TE path in VLAN-based traffic
forwarding network and MUST be unique.
8.2. Address TLVs
[RFC8779] defines IPV4-ADDRESS, IPV6-ADDRESS, and UNNUMBERED-ENDPOINT
TLVs for the use of Generalized Endpoint. The same TLVs can also be
used in the CCI object to find the Peer address that matches egress
PCC and further identify the packet to be guaranteed. If the PCC is
not able to resolve the peer information or can not find the
corresponding ingress device, it MUST reject the CCI and respond with
a PCErr message with Error-Type = TBD6 ("VLAN-based forwarding
failure") and Error Value = TBD9 ("Invalid egress PCC information").
8.3. VLAN crossing CCI Object
The VLAN crossing CCI object is defined to control the transmission-
path of the packet by VLAN-ID. This new type of CCI Object can be
carried within a PCInitiate message sent by the PCE to the transit
PCC and the egress PCC in the VLAN-based traffic forwarding
scenarios.
CCI Object-Class is 44.
CCI Object-Type is TBD10 for VLAN crossing info in the native IP
network.
Wang, et al. Expires 11 October 2024 [Page 18]
Internet-Draft pce April 2024
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved1 | Flags |O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID(in/out) | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Interface Address TLV //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Additional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: VLAN Crossing CCI Object
CC-ID: is as described in [RFC9050]. Following fields are defined
for CCI Object-Type TBD10.
Reserved1(16 bits): is set to zero while sending, ignored on receipt.
Flags(16 bits): is used to carry any additional information
pertaining to the CCI. Currently, the following flag bit are
defined:
* O bit (out-label) : If the bit is set to '1', it specifies the VLAN
is the out-VLAN, and it is mandatory to encode the egress interface
information(via Interface Address TLVs in the CCI object). If the
bit is not set or set to '0', it specifies the VLAN is the in-VLAN,
and it is mandatory to encode the ingress interface information.
VLAN ID(12 bits): The ID of the VLAN switching path. When the O bit
is set to 0, the VLAN is the in-VLAN and the ID indicates a VLAN
forwarding path which is used to identify the traffic that needs to
be protected. When the O bit is set to 1, the VLAN is the out-VLAN
and it indicates the ID of the VLAN forwarding path that the PCC will
set up on its logical subinterface in order to transfer the packet
labled with this VLAN ID to the specific hop. To the transit PCC,
the value must not be 0 to indicate it is not the last hop of the
VLAN-based traffic forwarding path. To the egress PCC, the value
must be 0 to indicate it is the last hop of the VLAN-based traffic
forwarding path.
Reserved2(8 bits): is set to zero while sending, ignored on receipt.
Wang, et al. Expires 11 October 2024 [Page 19]
Internet-Draft pce April 2024
Interface Address TLV [RFC8779] MUST be included in this CCI Object-
Type TBD8 to specify the interface which will set up the vlan defined
in the VLAN Forwarding CCI Object.
9. IANA Considerations
9.1. Path Setup Type Registry
[RFC8408] created a sub-registry within the "Path Computation Element
Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
IANA is requested to allocate a new code point within this registry,
as follows:
Value Description Reference
TBD1 VLAN-Based Traffic Forwarding Path This document
9.2. PCECC-CAPABILITY sub-TLV's Flag field
[RFC9050] created a sub- registry within the "Path Computation
Element Protocol (PCEP) Numbers" registry to manage the value of the
PCECC-CAPABILITY sub- TLV's 32-bits Flag field. IANA is requested to
allocate a new bit position within this registry, as follows:
Value Description Reference
TBD2(V) VLAN-Based Forwarding CAPABILITY This document
9.3. PCEP Object Types
IANA is requested to allocate new registry for the PCEP Object Type:
Object-Class Value Name Reference
44 CCI Object-Type This document
TBD8: VLAN forwarding CCI
TBD10: VLAN crossing CCI
9.4. PCEP-Error Object
IANA is requested to allocate new error types and error values within
the "PCEP-ERROR Object Error Types and Values" sub-registry of the
PCEP Numbers registry for the following errors:
Wang, et al. Expires 11 October 2024 [Page 20]
Internet-Draft pce April 2024
Error-Type Meaning Error-value Reference
6 Mandatory Object missing TBD4:VLAN-based This document
forwarding object
missing
10 Reception of an TBD3:PCECC This document
invalid object VLAN-based-forwarding
-CAPABILITY
bit is not set
19 Invalid Operation TBD5: Only one of BPI, This document
PPA or one type of
the CCI objects
for VLAN can be included
in this message
TBD6 VLAN-based forwarding TBD7: VLAN crossing CCI This document
failure Object peer info mismatch
TBD9: Invalid egress This document
PCC information
10. Normative References
[I-D.ietf-pce-pcep-extension-for-pce-controller]
Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou,
"Path Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", Work in Progress, Internet-
Draft, draft-ietf-pce-pcep-extension-for-pce-controller-
14, 5 March 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-pcep-extension-for-pce-controller-14>.
[I-D.ietf-pce-pcep-extension-native-ip]
Wang, A., Khasanov, B., Fang, S., Tan, R., and C. Zhu,
"Path Computation Element Communication Protocol (PCEP)
Extensions for Native IP Networks", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-extension-native-ip-
30, 1 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-extension-native-ip-30>.
[I-D.wang-vlan-based-traffic-forwarding]
Wang, Y., Wang, A., Khasanov, B., Qin, F., Chen, H., and
C. Zhu, "Dataplane Operations for VLAN Switching", Work in
Progress, Internet-Draft, draft-wang-vlan-based-traffic-
forwarding-01, 19 March 2024,
<https://datatracker.ietf.org/doc/html/draft-wang-vlan-
based-traffic-forwarding-01>.
Wang, et al. Expires 11 October 2024 [Page 21]
Internet-Draft pce April 2024
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231lt;Define the names,
types, and text value encoding formats of the FEC-Scheme-
Specific Information elements>
3. Procedures <Describe any procedures that are specific to this
FEC scheme, in particular derivation and interpretation of the
fields in the FEC Payload IDs and FEC-Scheme-Specific
Information>
4. FEC Code Specification <Provide a complete specification of the
FEC Code>
Specifications can include additional sections including examples.
Each FEC scheme MUST be specified independently of all other FEC
schemes, for example, in a separate specification or a completely
independent section of a larger specification (except, of course, a
specification of one FEC scheme can include portions of another by
reference). Where an RTP payload format is defined for repair data
for a specific FEC scheme, the RTP payload format and the FEC scheme
can be specified within the same document.
6. Feedback
Many applications require some kind of feedback on transport
performance, e.g., how much data arrived at the receiver, at what
rate, and when? When FEC is added to such applications, feedback
mechanisms may also need to be enhanced to report on the performance
of the FEC, e.g., how much lost data was recovered by the FEC?
Watson, et al. Standards Track [Page 26]
RFC 6363 FEC Framework October 2011
When used to provide instrumentation for engineering purposes, it is
important to remember that FEC is generally applied to relatively
small blocks of data (in the sense that each block is transmitted
over a relatively small period of time). Thus, feedback information
that is averaged over longer periods of time will likely not provide
sufficient information for engineering purposes. More detailed
feedback over shorter time scales might be preferred. For example,
for applications using RTP transport, see [RFC5725].
Applications that use feedback for congestion control purposes MUST
calculate such feedback on the basis of packets received before FEC
recovery is applied. If this requirement conflicts with other uses
of the feedback information, then the application MUST be enhanced to
support information calculated both pre- and post-FEC recovery. This
is to ensure that congestion control mechanisms operate correctly
based on congestion indications received from the network, rather
than on post-FEC recovery information that would give an inaccurate
picture of congestion conditions.
New applications that require such feedback SHOULD use RTP/RTCP
[RFC3550].
7. Transport Protocols
This framework is intended to be used to define CDPs that operate
over transport protocols providing an unreliable datagram service,
including in particular the User Datagram Protocol (UDP) and the
Datagram Congestion Control Protocol (DCCP).
8. Congestion Control
This section starts with some informative background on the
motivation of the normative requirements for congestion control,
which are spelled out in Section 8.2.
8.1. Motivation
o The enforcement of congestion control principles has gained a lot
of momentum in the IETF over recent years. While the need for
congestion control over the open Internet is unquestioned, and the
goal of TCP friendliness is generally agreed upon for most (but
not all) applications, the problem of congestion detection and
measurement in heterogeneous networks can hardly be considered
solved. Most congestion control algorithms detect and measure
congestion by taking (primarily or exclusively) the packet loss
rate into account. This appears to be inappropriate in
environments where a large percentage of the packet losses are the
result of link-layer errors and independent of the network load.
Watson, et al. Standards Track [Page 27]
RFC 6363 FEC Framework October 2011
o The authors of this document are primarily interested in
applications where the application reliability requirements and
end-to-end reliability of the network differ, such that it
warrants higher-layer protection of the packet stream, e.g., due
to the presence of unreliable links in the end-to-end path and
where real-time, scalability, or other constraints prohibit the
use of higher-layer (transport or application) feedback. A
typical example for such applications is multicast and broadcast
streaming or multimedia transmission over heterogeneous networks.
In other cases, application reliability requirements can be so
high that the required end-to-end reliability will be difficult to
achieve. Furthermore, the end-to-end network reliability is not
necessarily known in advance.
o This FEC Framework is not defined as, nor is it intended to be, a
quality-of-service (QoS) enhancement tool to combat losses
resulting from highly congested networks. It should not be used
for such purposes.
o In order to prevent such misuse, one approach is to leave
standardization to bodies most concerned with the problem
described above. However, the IETF defines base standards used by
several bodies, including the Digital Video Broadcasting (DVB)
Project, the Third Generation Partnership Project (3GPP), and
3GPP2, all of which appear to share the environment and the
problem described.
o Another approach is to write a clear applicability statement. For
example, one could restrict the use of this framework to networks
with certain loss characteristics (e.g., wireless links).
However, there can be applications where the use of FEC is
justified to combat congestion-induced packet losses --
particularly in lightly loaded networks, where congestion is the
result of relatively rare random peaks in instantaneous traffic
load -- thereby intentionally violating congestion control
principles. One possible example for such an application could be
a no-matter-what, brute-force FEC protection of traffic generated
as an emergency signal.
o A third approach is to require, at a minimum, that the use of this
framework with any given application, in any given environment,
does not cause congestion issues that the application alone would
not itself cause; i.e., the use of this framework must not make
things worse.
Watson, et al. Standards Track [Page 28]
RFC 6363 FEC Framework October 2011
o Taking the above considerations into account, Section 8.2
specifies a small set of constraints for FEC; these constraints
are mandatory for all senders compliant with this FEC Framework.
Further restrictions can be imposed by certain CDPs.
8.2. Normative Requirements
o The bandwidth of FEC repair data MUST NOT exceed the bandwidth of
the original source data being protected (without the possible
addition of an Explicit Source FEC Payload ID). This disallows
the (static or dynamic) use of excessively strong FEC to combat
high packet loss rates, which can otherwise be chosen by naively
implemented dynamic FEC-strength selection mechanisms. We
acknowledge that there are a few exotic applications, e.g., IP
traffic from space-based senders, or senders in certain hardened
military devices, that could warrant a higher FEC strength.
However, in this specification, we give preference to the overall
stability and network friendliness of average applications.
o Whenever the source data rate is adapted due to the operation of
congestion control mechanisms, the FEC repair data rate MUST be
similarly adapted.
9. Security Considerations
First of all, it must be clear that the application of FEC protection
to a stream does not provide any kind of security. On the contrary,
the FEC Framework itself could be subject to attacks or could pose
new security risks. The goals of this section are to state the
problem, discuss the risks, and identify solutions when feasible. It
also defines a mandatory-to-implement (but not mandatory-to-use)
security scheme.
9.1. Problem Statement
A content delivery system is potentially subject to many attacks.
Attacks can target the content, the CDP, or the network itself, with
completely different consequences, particularly in terms of the
number of impacted nodes.
Attacks can have several goals:
o They can try to give access to confidential content (e.g., in the
case of non-free content).
o They can try to corrupt the source flows (e.g., to prevent a
receiver from using them), which is a form of denial-of-service
(DoS) attack.
Watson, et al. Standards Track [Page 29]
RFC 6363 FEC Framework October 2011
o They can try to compromise the receiver's behavior (e.g., by
making the decoding of an object computationally expensive), which
is another form of DoS attack.
o They can try to compromise the network's behavior (e.g., by
causing congestion within the network), which potentially impacts
a large number of nodes.
These attacks can be launched either against the source and/or repair
flows (e.g., by sending fake FEC source and/or repair packets) or
against the FEC parameters that are sent either in-band (e.g., in the
Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or
out-of-band (e.g., in the FEC Framework Configuration Information).
Several dimensions to the problem need to be considered. The first
one is the way the FEC Framework is used. The FEC Framework can be
used end-to-end, i.e., it can be included in the final end-device
where the upper application runs, or the FEC Framework can be used in
middleboxes, for instance, to globally protect several source flows
exchanged between two or more distant sites.
A second dimension is the threat model. When the FEC Framework
operates in the end-device, this device (e.g., a personal computer)
might be subject to attacks. Here, the attacker is either the end-
user (who might want to access confidential content) or somebody
else. In all cases, the attacker has access to the end-device but
does not necessarily fully control this end-device (a secure domain
can exist). Similarly, when the FEC Framework operates in a
middlebox, this middlebox can be subject to attacks or the attacker
can gain access to it. The threats can also concern the end-to-end
transport (e.g., through the Internet). Here, examples of threats
include the transmission of fake FEC source or repair packets; the
replay of valid packets; the drop, delay, or misordering of packets;
and, of course, traffic eavesdropping.
The third dimension consists in the desired security services. Among
them, the content integrity and sender authentication services are
probably the most important features. We can also mention DoS
mitigation, anti-replay protection, or content confidentiality.
Finally, the fourth dimension consists in the security tools
available. This is the case of the various Digital Rights Management
(DRM) systems, defined outside of the context of the IETF, that can
be proprietary solutions. Otherwise, the Secure Real-Time Transport
Protocol (SRTP) [RFC3711] and IPsec/Encapsulating Security Payload
(IPsec/ESP) [RFC4303] are two tools that can turn out to be useful in
the context of the FEC Framework. Note that using SRTP requires that
the application generate RTP source flows and, when applied below the
Watson, et al. Standards Track [Page 30]
RFC 6363 FEC Framework October 2011
FEC Framework, that both the FEC source and repair packets be regular
RTP packets. Therefore, SRTP is not considered to be a universal
solution applicable in all use cases.
In the following sections, we further discuss security aspects
related to the use of the FEC Framework.
9.2. Attacks against the Data Flows
9.2.1. Access to Confidential Content
Access control to the source flow being transmitted is typically
provided by means of encryption. This encryption can be done by the
content provider itself, or within the application (for instance, by
using SRTP [RFC3711]), or at the network layer on a per-packet basis
when IPsec/ESP is used [RFC4303]. If confidentiality is a concern,
it is RECOMMENDED that one of these solutions be used. Even if we
mention these attacks here, they are neither related to nor
facilitated by the use of FEC.
Note that when encryption is applied, this encryption MUST be applied
either on the source data before the FEC protection or, if done after
the FEC protection, on both the FEC source packets and repair packets
(and an encryption at least as cryptographically secure as the
encryption applied on the FEC source packets MUST be used for the FEC
repair packets). Otherwise, if encryption were to be performed only
on the FEC source packets after FEC encoding, a non-authorized
receiver could be able to recover the source data after decoding the
FEC repair packets, provided that a sufficient number of such packets
were available.
The following considerations apply when choosing where to apply
encryption (and more generally where to apply security services
beyond encryption). Once decryption has taken place, the source data
is in plaintext. The full path between the output of the deciphering
module and the final destination (e.g., the TV display in the case of
a video) MUST be secured, in order to prevent any unauthorized access
to the source data.
When the FEC Framework endpoint is the end-system (i.e., where the
upper application runs) and if the threat model includes the
possibility that an attacker has access to this end-system, then the
end-system architecture is very important. More precisely, in order
to prevent an attacker from getting hold of the plaintext, all
processing, once deciphering has taken place, MUST occur in a
protected environment. If encryption is applied after FEC protection
Watson, et al. Standards Track [Page 31]
>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
"Scenarios and Simulation Results of PCE in a Native IP
Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
<https://www.rfc-editor.org/info/rfc8735>.
[RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F.
Zhang, Ed., "Path Computation Element Communication
Protocol (PCEP) Extensions for GMPLS", RFC 8779,
DOI 10.17487/RFC8779, July 2020,
<https://www.rfc-editor.org/info/rfc8779>.
Wang, et al. Expires 11 October 2024 [Page 22]
Internet-Draft pce April 2024
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
Authors' Addresses
Yue Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangy73@chinatelecom.cn
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn
Boris Khasanov
Yandex LLC
Ulitsa Lva Tolstogo 16
Moscow
Email: bhassanov@yandex-team.ru
Fengwei Qin
China Mobile
32 Xuanwumenxi Ave.
Beijing
100032
China
Email: qinfengwei@chinamobile.com
Huaimo Chen
Futurewei
Boston,
United States of America
Email: Huaimo.chen@futurewei.com
Wang, et al. Expires 11 October 2024 [Page 23]
Internet-Draft pce April 2024
Chun Zhu
ZTE Corporation
50 Software Avenue, Yuhua District
Nanjing
Jiangsu, 210012
China
Email: zhu.chun1@zte.com.cn
Wang, et al. Expires 11 October 2024 [Page 24]