draft-ietf-fecframe-config-signaling-00.txt   draft-ietf-fecframe-config-signaling-01.txt 
FECFRAME Working Group Rajiv Asati FECFRAME Working Group Rajiv Asati
Internet Draft Cisco Systems Internet Draft Cisco Systems
Intended status: Standards Track July 4, 2008 Intended status: Standards Track
Expires: January 2009 Expires: May 2009 November 1, 2008
Signaling Protocol to convey FEC Framework Configuration Information Methods to convey FEC Framework Configuration Information
draft-ietf-fecframe-config-signaling-00.txt draft-ietf-fecframe-config-signaling-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 2, 2008. This Internet-Draft will expire on May 1, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
FEC Framework document [FECARCH] defines the FEC Framework FEC Framework document [FECARCH] defines the FEC Framework
Configuration Information necessary for the FEC framework operation. Configuration Information necessary for the FEC framework operation.
This document describes one signaling protocol to determine and This document describes how to use existing signaling protocols to
dynamically communicate the Configuration information between determine and dynamically communicate the Configuration information
sender(s) and receiver(s). between sender(s) and receiver(s).
Conventions used in this document Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4. Signaling Protocol.............................................6 4. Signaling Protocol.............................................6
4.1. Signaling Protocol for Multicasting.......................7 4.1. Signaling Protocol for Multicasting.......................7
4.1.1. Sender Procedure.....................................9 4.1.1. Sender Procedure.....................................9
4.1.2. Receiver Procedure..................................10 4.1.2. Receiver Procedure..................................10
4.2. Signaling Protocol for Unicasting........................11 4.2. Signaling Protocol for Unicasting........................11
4.2.1. SIP.................................................12 4.2.1. SIP.................................................12
4.2.2. RSTP................................................12 4.2.2. RSTP................................................12
4.2.3. DSM-CC..............................................13 4.2.3. DSM-CC..............................................13
5. Security Considerations.......................................13 5. Security Considerations.......................................13
6. IANA Considerations...........................................13 6. IANA Considerations...........................................13
7. Conclusions...................................................14 7. Conclusions...................................................13
8. Acknowledgments...............................................14 8. Acknowledgments...............................................14
9. References....................................................15 9. References....................................................15
9.1. Normative References.....................................15 9.1. Normative References.....................................15
9.2. Informative References...................................15 9.2. Informative References...................................15
Author's Addresses...............................................16 Author's Addresses...............................................16
Intellectual Property Statement..................................16 Intellectual Property Statement..................................16
Disclaimer of Validity...........................................16 Disclaimer of Validity...........................................16
1. Introduction 1. Introduction
FEC Framework document [FECARCH] defines the FEC Framework FEC Framework document [FECARCH] defines the FEC Framework
Configuration Information that governs the overall FEC framework Configuration Information that governs the overall FEC framework
operation common to any FEC scheme. This information MUST be operation common to any FEC scheme. This information MUST be
available at both sender and reciever(s). This document describes one available at both sender and reciever(s). This document describes how
signalling protocol to determine and communicate the Configuration to use various signaling protocols to determine and communicate the
information between sender and receiver(s). The configuration Configuration information between sender and receiver(s). The
information may be encoded in any compatible format such as SDP configuration information may be encoded in any compatible format
[RFC4566], XML etc. The signaling protocol is intended to be generic such as SDP [RFC4566], XML etc. A signaling protocol could be
and could be utilized by any FEC scheme and/or any Content Delivery utilized by any FEC scheme and/or any Content Delivery Protocol
Protocol (CDP). (CDP).
This document doesn't describe any FEC scheme specifics information This document doesn't describe any FEC scheme specifics information
(for example, how are source blocks are constructed) or any sender or (for example, how are source blocks are constructed) or any sender or
receiver side operation for a particular FEC scheme (for example, receiver side operation for a particular FEC scheme (for example,
whether the receiver makes use of one or more repair flows that are whether the receiver makes use of one or more repair flows that are
received) etc. Such FEC scheme specifics should be covered in received) etc. Such FEC scheme specifics should be covered in
separate document(s). This document doesn't mandate a particular separate document(s). This document doesn't mandate a particular
encoding format for the configuration information either. encoding format for the configuration information either.
<What is CDP> <What is CDP>
The FEC Framework document [FECARCH] defines a Content Delivery Content Delivery Protocol (CDP) is defined as a complete (suite of)
Protocol (CDP) as a complete (suite of) specification which, through specification which, through the use of FEC Framework, is able to
the use of FEC Framework, is able to make use of a particular FEC make use of FEC scheme(s) to provide FEC capabilities. In other
scheme to provide FEC capabilities. In other words, CDP is specific words, CDP makes use of common building blocks (including signaling
to a FEC scheme, but makes use of common building blocks (including protocol) as defined in the FEC Framework document [FECARCH].
signaling protocol) as defined in the FEC Framework document
[FECARCH].
This document is structured such that Section 2 describes the terms This document is structured such that Section 2 describes the terms
used in this document, section 3 describes the FEC Framework used in this document, section 3 describes the FEC Framework
configuration information, section 4 describes the signalling configuration information, section 4 describes how to use signaling
protocol for the multicast, section 5 describes the signalling protocol for the multicast application, section 5 describes the
protocol for the unicast, and section 6 describes security signaling protocol for the unicast application, and section 6
consideration. describes security consideration.
Copyright (C) The IETF Trust (2008). This version of this MIB module Copyright (C) The IETF Trust (2008). This version of this MIB module
is part of RFC XXXX; see the RFC itself for full legal notices. is part of RFC XXXX; see the RFC itself for full legal notices.
Copyright (C) The IETF Trust (2008). The initial version of this MIB
module was published in RFC XXXX; for full legal notices see the RFC
itself. Supplementary information may be available at:
http://www.ietf.org/copyrights/ianamib.html.
2. Terminology/Abbreviations 2. Terminology/Abbreviations
This document makes use of the terms/abbreviations defined in the FEC This document makes use of the terms/abbreviations defined in the FEC
Framework document [FECARCH]. Additionally, it defines Framework document [FECARCH]. Additionally, it defines
o Media Sender - Node performing the Media encoding and producing o Media Sender - Node performing the Media encoding and producing
the original media flow to the 'FEC Sender' the original media flow to the 'FEC Sender'
o Media Receiver - Node performing the Media decoding; o Media Receiver - Node performing the Media decoding;
o FEC Sender - Node performing the FEC encoding on the original o FEC Sender - Node performing the FEC encoding on the original
stream to produce the FEC stream stream to produce the FEC stream
o FEC Receiver - Node performing the FEC decoding, as needed, and o FEC Receiver - Node performing the FEC decoding, as needed, and
providing the original media flow to the Media receiver. providing the original media flow to the Media receiver.
o Sender - Same as FEC Sender o Sender - Same as FEC Sender
o Receiver - Same as FEC Receiver o Receiver - Same as FEC Receiver
o (Media) Stream - A single media instance i.e. an audio stream or o (Media) Stream - A single media instance i.e. an audio stream or
a video stream. a video stream.
skipping to change at page 4, line 22 skipping to change at page 4, line 14
o FEC Receiver - Node performing the FEC decoding, as needed, and o FEC Receiver - Node performing the FEC decoding, as needed, and
providing the original media flow to the Media receiver. providing the original media flow to the Media receiver.
o Sender - Same as FEC Sender o Sender - Same as FEC Sender
o Receiver - Same as FEC Receiver o Receiver - Same as FEC Receiver
o (Media) Stream - A single media instance i.e. an audio stream or o (Media) Stream - A single media instance i.e. an audio stream or
a video stream. a video stream.
This documents deliberately refers to the 'FEC Sender' and 'FEC This document deliberately refers to the 'FEC Sender' and 'FEC
Receiver' as the 'Sender' and 'Receiver' respectively. Receiver' as the 'Sender' and 'Receiver' respectively.
3. FEC Framework Configuration Information 3. FEC Framework Configuration Information
The FEC Framework [FECARCH] defines a minimum set of information that The FEC Framework [FECARCH] defines a minimum set of information that
MUST be communicated between the sender and receiver(s) for a proper MUST be communicated between the sender and receiver(s) for a proper
operation of an FEC scheme. This information is referred to as "FEC operation of an FEC scheme. This information is referred to as "FEC
Framework Configuration Information". This is the information that Framework Configuration Information". This is the information that
the FEC Framework needs in order to apply FEC protection to the the FEC Framework needs in order to apply FEC protection to the
transport flows. transport flows.
skipping to change at page 5, line 4 skipping to change at page 4, line 37
all packets of a specified set of source packet flows, by means of all packets of a specified set of source packet flows, by means of
one or more packet flows consisting of repair packets. As per the FEC one or more packet flows consisting of repair packets. As per the FEC
Framework document [FECARCH], the FEC Framework Configuation Framework document [FECARCH], the FEC Framework Configuation
Information includes, for each instance of the FEC Framework: Information includes, for each instance of the FEC Framework:
1. Identification of Source Flow(s) 1. Identification of Source Flow(s)
2. Identification of the repair flow(s) 2. Identification of the repair flow(s)
3. Identification of FEC Scheme 3. Identification of FEC Scheme
4. Length of Source FEC payload ID 4. Length of Source FEC payload ID
5. FEC Scheme Specific Information (FSSI) 5. FEC Scheme Specific Information (FSSI)
FSSI basically provides an opaque container to encode FEC scheme FSSI basically provides an opaque container to encode FEC scheme
specific configuration information such as buffer size, decoding specific configuration information such as buffer size, decoding
wait-time etc. Please refer to the FEC Framework document [FECARCH] wait-time etc. Please refer to the FEC Framework document [FECARCH]
for more details. for more details.
The signaling protocol described in this document requires that the The usage of signaling protocols described in this document requires
application layer responsible for the FEC Framework instance i.e. FEC that the application layer responsible for the FEC Framework instance
scheme provide the value for each of the configuration information i.e. FEC scheme provide the value for each of the configuration
parameter (listed above) encoded as per the chosen encoding format. information parameter (listed above) encoded as per the chosen
Failure to receive the complete information, the signaling protocol encoding format. Failure to receive the complete information, the
module must return an error for the OAM purposes and optionally signaling protocol module must return an error for the OAM purposes
convey to the application layer. Please refer to the figure 1 of the and optionally convey to the application layer. Please refer to the
FEC Framework document [FECARCH] for further illustration. figure 1 of the FEC Framework document [FECARCH] for further
illustration.
This document does not make any assumption that the 'FEC sender and This document does not make any assumption that the 'FEC sender and
receiver' functionality and the 'Media Source/Receiver' functionality receiver' functionality and the 'Media Source/Receiver' functionality
are implemented on the single device, though it is likely to be the are implemented on the single device, though it may be the case.
case.
3.1. Encoding Format 3.1. Encoding Format
The FEC Framework configuration information (listed above in section The FEC Framework configuration information (listed above in section
3) may be encoded in any format such as SDP, XML etc. as chosen or 3) may be encoded in any format such as SDP, XML etc. as chosen or
prefered by a particular FEC Framework instance i.e. FEC Scheme. The prefered by a particular FEC Framework instance i.e. FEC Scheme. The
selection of such encoding format or syntax is independent of the selection of such encoding format or syntax is independent of the
signaling protocol and beyond the scope of this document. signaling protocol and beyond the scope of this document.
Whatever encoding format is selected for a particular FEC framework Whatever encoding format is selected for a particular FEC framework
instance, it must be known by the signaling protocol. This is to instance, it must be known by the signaling protocol. This is to
provide a mean (e.g. a field such as Payload Type) in the signaling provide a mean (e.g. a field such as Payload Type) in the signaling
protocol message(s) to convey the chosen encoding format for the protocol message(s) to convey the chosen encoding format for the
configuration information so that the Payload i.e. configuration configuration information so that the Payload i.e. configuration
information can be correctly parsed as per the semantics of the information can be correctly parsed as per the semantics of the
chosen encoding format. Please note that the the encoding format is chosen encoding format at the receiver. Please note that the encoding
not a negotiated parameter, but rather a property of a particular FEC format is not a negotiated parameter, but rather a property of a
Framework instance i.e. FEC scheme and/or its implementation. particular FEC Framework instance i.e. FEC scheme and/or its
implementation.
Additionally, the encoding format for each FEC Framework Additionally, the encoding format for each FEC Framework
configuration parameter must be defined in terms of a sequence of configuration parameter must be defined in terms of a sequence of
octets that can be embedded within the payload of the signaling octets that can be embedded within the payload of the signaling
protocol message(s). The length of the encoding format MUST either protocol message(s). The length of the encoding format MUST either
be fixed, or derived from examining the encoded octets themselves. be fixed, or derived by examining the encoded octets themselves. For
For example, the initial octets may include some kind of length example, the initial octets may include some kind of length
indication. indication.
Each instance of the FEC Framework muse use a single encoding format Each instance of the FEC Framework muse use a single encoding format
to describe e.g. encode all of the configuration information to describe e.g. encode all of the configuration information
associated with that instance. The signaling protocol may not associated with that instance. The signaling protocol may not
validate the encoded information, though it may validate the syntax validate the encoded information, though it may validate the syntax
or length of the encoded information. or length of the encoded information.
The reader may refer to the SDP elements document [FECSDP], which The reader may refer to the SDP elements document [FECSDP], which
describes the usage of 'SDP' encoding format as an example encoding describes the usage of 'SDP' encoding format as an example encoding
format for FEC framework configuration information. format for FEC framework configuration information.
4. Signaling Protocol 4. Signaling Protocol Usage
FEC Framework [FECARCH] requires certain FEC Framework Configuration FEC Framework [FECARCH] requires certain FEC Framework Configuration
Information to be available to both sender and receiver(s). This Information to be available to both sender and receiver(s). This
configuration information is almost always formulated at the sender configuration information is almost always formulated at the sender
(or on behalf of a sender), the receiver(s) somehow must get this (or on behalf of a sender), the receiver(s) somehow must get this
configuration information. While one may envision a static method to configuration information. While one may envision a static method to
populate the configuration information at both sender and populate the configuration information at both sender and
receiver(s), it would require the knowledge of every receiver in receiver(s), it would require the knowledge of every receiver in
advance and that is something not always feasible. Hence, there is a advance and that is something not always feasible. Hence, there is a
desire to define and describe dynamic method i.e. signaling protocol desire to describe using methods i.e. signaling protocol to convey
to convey the configuration information from sender to one or more the configuration information between sender and one or more
receivers. receivers.
It is important to note that there may be either only one receiver It is important to note that there may be either only one receiver
needing the FEC Framework configuration information to FEC protect a needing the FEC Framework configuration information to FEC protect a
"unicasted multimedia stream" (such as Video On Demand stream), or "unicasted multimedia stream" (such as Video On Demand stream), or
one or more receivers needing the FEC Framework configuration one or more receivers needing the FEC Framework configuration
information to FEC protect a "multicasted multimedia stream" (such as information to FEC protect a "multicasted multimedia stream" (such as
Broadcast TV or IPTV). While the unicasted stream requires the Broadcast TV or IPTV). While the unicasted stream requires the
identification of the receiver (which typically initiates the identification of the receiver at the sender, the multicasted stream
communication) at the sender, the multicasted stream doesn't require doesn't necessarily require the identification of the receiver at the
the identification of the receiver at the sender. sender.
Such diversity necessitates describing at least two signaling Such diversity necessitates describing using at least two types of
protocols - one to deliver the configuration information to many signaling protocols - one to deliver the configuration information to
receivers via multicasting (described in section 4.1), and the other many receivers via multicasting (described in section 4.1), and the
to deliver the configuration information to one and only one receiver other to deliver the configuration information to one and only one
via unicasting (described in section 4.2). receiver via unicasting (described in section 4.2).
Figure 1 below illustrates a sample topology showing the FEC sender Figure 1 below illustrates a sample topology showing the FEC sender
and FEC receiver (that may or may not be the Media Sender and Media and FEC receiver (that may or may not be the Media Sender and Media
Receiver respectively) such that FEC_Sender1 is serving Receiver respectively) such that FEC_Sender1 is serving
FEC_Reciver11,12,13 via the multicast signaling protocol, whereas the FEC_Reciver11,12,13 via the multicast signaling protocol, whereas the
FEC_Sender2 is serving only FEC_Reciever2 via the unicast signaling FEC_Sender2 is serving only FEC_Reciever2 via the unicast signaling
protocol. protocol.
FEC_Sender2---------| |--------FEC_Receiver2 FEC_Sender2---------| |--------FEC_Receiver2
| | | |
skipping to change at page 7, line 27 skipping to change at page 7, line 22
|-----------FEC_Receiver13 |-----------FEC_Receiver13
Figure 1 Topology using Sender and Receiver Figure 1 Topology using Sender and Receiver
The rest of the section continues to use the terms 'Sender' and The rest of the section continues to use the terms 'Sender' and
'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver' 'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver'
respectively. respectively.
4.1. Signaling Protocol for Multicasting 4.1. Signaling Protocol for Multicasting
A one-to-many signaling protocol is desired in order to effectively This specification describes using Session Announcement Protocol
deliver the FEC Framework configuration from one sender to many (SAP) version 2 [RFC2974] as the signaling protocol to multicast the
receivers. The Session Announcement Protocol (SAP) version 2 configuration information from one sender to many receivers. The
[RFC2974] is used as the signaling protocol to multicast the apparent advantage is that the server doesn't need to maintain any
configuration information. The apparent advantage is that the server state for any receiver using SAP.
doesn't need to maintain any state for any receiver using SAP.
At the high level, a sender, acting as the SAP announcer, signals the At the high level, a sender, acting as the SAP announcer, signals the
FEC Framework Configuration Information for each FEC Framework FEC Framework Configuration Information for each FEC Framework
instance available at the sender, using the SAP message(s). The instance available at the sender, using the SAP message(s). The
configuration information, encoded in a suitable format as per the configuration information, encoded in a suitable format as per the
section 3.1, is carried in the Payload of the SAP message(s). A section 3.1, is carried in the Payload of the SAP message(s). A
receiver, acting as the SAP listener, listens on a well known UDP receiver, acting as the SAP listener, listens on a well known UDP
port and at least one well known multicast group IP address. This port and at least one well known multicast group IP address. This
enables the receiver to receives the SAP message(s) and obtains the enables the receiver to receive the SAP message(s) and obtains the
FEC Framework Configuration Information for each FEC Framework FEC Framework Configuration Information for each FEC Framework
Instance. Instance.
Using the configuration information, the receiver becomes aware of Using the configuration information, the receiver becomes aware of
available FEC protection options, and may subscribe to one or more available FEC protection options, and may subscribe to one or more
multicast trees to receive the FEC streams using out-of-band multicast trees to receive the FEC streams using out-of-band
multicasting techniques such as PIM [RFC4601]. This, however, is multicasting techniques such as PIM [RFC4601]. This, however, is
beyond the specification of this document. outside the scope of this document.
SAP message is carried over UDP over IP. The destination UDP port SAP message is carried over UDP over IP. The destination UDP port
must be 9875 and source UDP port may be any available number. The SAP must be 9875 and source UDP port may be any available number. The SAP
message(s) SHOULD contain an authentication header and MAY be message(s) SHOULD contain an authentication header and MAY be
subjected to the cryptography. One cryptography method suggested by subjected to the cryptography. One cryptography method suggested by
this specification is the usage of Group Cryptography as specified in this specification is the usage of Group Cryptography as specified in
GDOI [RFC3547]. GDOI [RFC3547].
Figure 2 below illustrates the SAP packet format (it is reprinted Figure 2 below illustrates the SAP packet format (it is reprinted
from the RFC2974) - from the RFC2974) -
skipping to change at page 8, line 44 skipping to change at page 8, line 38
+ +-+- - - - - - - - - -+ + +-+- - - - - - - - - -+
| |0| | | |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ | + - - - - - - - - - - - - - - - - - - - - +-+ |
| | | |
: payload : : payload :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 SAP Message format Figure 2 SAP Message format
While the RFC2974 includes explanation for each field, the most While the RFC2974 includes explanation for each field, it is worth
interesting is the 'Payload' field. This field is required, by this discussing the 'Payload' and 'Payload Type' field. This field must be
specification, to carry the the FEC Framework configuration used to carry the FEC Framework configuration information.
information. Subsequently, the 'Payload Type' field, which is a MIME Subsequently, the optional 'Payload Type' field, which is a MIME
content type specifier, must describe the encoding format used to content type specifier, must describe the encoding format used to
encode the Payload. For example, the 'Payload Type' field may be encode the Payload. For example, the 'Payload Type' field may be
application/sdp if the FEC framework configuration information was application/sdp if the FEC framework configuration information is
encoded in SDP format and placed as SAP payload. Similarly, it would encoded in SDP format and carried in the SAP payload. Similarly, it
be application/xml if the FEC framework configuration information was would be application/xml if the FEC framework configuration
encoded in XML format. information was encoded in XML format.
4.1.1. Sender Procedure 4.1.1. Sender Procedure
The sender signals the FEC framework configuration for each FEC The sender signals the FEC framework configuration for each FEC
framework instance in a periodic SAP announcement message. The SAP framework instance in a periodic SAP announcement message. The SAP
announcement message is sent to a well known multicast IP address and announcement message is sent to a well known multicast IP address and
port. The announcement is multicasted with the same scope as the port. The announcement is multicasted with the same scope as the
session it is announcing. session being announced.
The SAP module at the sender obtains the FEC Framework configuration The SAP module at the sender obtains the FEC Framework configuration
information per Instance from the 'FEC Framework' module and places information per Instance from the 'FEC Framework' module and places
that in the SAP payload accordingly. A single SAP (announcement) that in the SAP payload accordingly. A single SAP (announcement)
message may carry the FEC Framework Configuration Information for message may carry the FEC Framework Configuration Information for
each FEC Framework Instance. This is a preferred method, though the each FEC Framework Instance. This is the preferred method, though the
other method may be to aggregate more than one SAP (announcement) other method may be to aggregate more than one SAP (announcement)
messages in a single UDP datagram as long as the resulting UDP messages in a single UDP datagram as long as the resulting UDP
datagram length is less than the IP MTU of the outgoing interface. datagram length is less than the IP MTU of the outgoing interface.
The IP packet carrying the SAP message must be sent with destination The IP packet carrying the SAP message must be sent to destination IP
IP address of either 239.16.33.254 (if IPv4 administrative scope 239. address of either 239.16.33.254 (if IPv4 administrative scope
is selected) or 224.2.127.254 (if IPv4 global scope 224.0.1.0- 239.0.0.0-239.255.255.255 is selected) or 224.2.127.254 (if IPv4
238.255.255.255 is selected) or FF0X:0:0:0:0:0:2:7FFE (if IPv6 is global scope 224.0.1.0-238.255.255.255 is selected) or
selected, where X is the 4-bit scope value) with UDP destination port FF0X:0:0:0:0:0:2:7FFE (if IPv6 is selected, where X is the 4-bit
9875. The default IP TTL value should be 255, though the scope value) with UDP destination port 9875. The default IP TTL value
implementation should allow to set it to any other value. The IP DSCP should be 255, though the implementation should allow to set it to
field may be set to any value that indicates a desired QoS treatment any other value. The IP DSCP field may be set to any value that
in the IP network. indicates a desired QoS treatment in the IP network.
The IP packet carrying the SAP message must be sent with source IP The IP packet carrying the SAP message must be sent with source IP
address that is reachable by the receiver. The sender may assign the address that is reachable by the receiver. The sender may assign the
same IP address in the "originating source" field of the SAP message, same IP address in the "originating source" field of the SAP message,
as the one used in the source IP address of the IP packet. as the one used in the source IP address of the IP packet.
Furthermore, the FEC Framework Configuration Information must NOT Furthermore, the FEC Framework Configuration Information must NOT
include any of the reserved multicast group IP addresses for the FEC include any of the reserved multicast group IP addresses for the FEC
streams (i.e. source or repair flows), though it may use the same IP streams (i.e. source or repair flows), though it may use the same IP
address as the 'originating source' address to identify the FEC address as the 'originating source' address to identify the FEC
skipping to change at page 10, line 17 skipping to change at page 10, line 10
entry(s) from the database and doesn't trigger the deletion of FEC entry(s) from the database and doesn't trigger the deletion of FEC
Framework configuration information. While the time interval between Framework configuration information. While the time interval between
repetitions of an announcement can be calculated as per the very repetitions of an announcement can be calculated as per the very
sophisticated but complex formula explained in RFC2974, the preferred sophisticated but complex formula explained in RFC2974, the preferred
and simpler mean is to let the user specify the time interval from and simpler mean is to let the user specify the time interval from
the range of 1-200 seconds with suggested default being 60 seconds. the range of 1-200 seconds with suggested default being 60 seconds.
The time interval must be chosen to ensure that SAP announcement The time interval must be chosen to ensure that SAP announcement
message is sent out before the corresponding multicast routing entry message is sent out before the corresponding multicast routing entry
(S,G) or (*,G) on the router doesn't time out. It is worth noting (S,G) or (*,G) on the router doesn't time out. It is worth noting
that the default time-out period for the multicast routing entry is that the default time-out period for the multicast routing entry is
210 seconds, per the PIM specification [RFC4601], but it depends on 210 seconds, per the PIM specification [RFC4601], though it may
the implementation. The implementation of signaling protocol should depend on the implementation. The SAP implementation should provide
provide the flexibility to the operator to choose the complex method the flexibility to the operator to choose the complex method over the
over the simpler method of determining the SAP announcement time simpler method of determining the SAP announcement time interval.
interval. Additionally, the 'time interval' should be signaled within Additionally, the 'time interval' should be signaled within the FEC
the FEC Framework configuration Information. Framework configuration Information.
The sender may choose to delete the announced FEC framework The sender may choose to delete the announced FEC framework
configuration information by sending a 'SAP deletion' message. This configuration information by sending a 'SAP deletion' message. This
may be used if the sender no longer desires to send any FEC streams. may be used if the sender no longer desires to send any FEC streams.
If the sender needs to modify the announced FEC Framework If the sender needs to modify the announced FEC Framework
configuration Information for one or more FEC instances, then the configuration Information for one or more FEC instances, then the
sender must send a new announcement message with a different 'Message sender must send a new announcement message with a different 'Message
Identifier Hash' value as per the rules described in section 5 of Identifier Hash' value as per the rules described in section 5 of
RFC2974. Such announcement message should be sent immediately RFC2974. Such announcement message should be sent immediately
(without having to wait for the time-interval) to ensure that the (without having to wait for the time-interval) to ensure that the
skipping to change at page 11, line 9 skipping to change at page 11, line 5
The receiver, upon receiving a SAP announcement message, creates an The receiver, upon receiving a SAP announcement message, creates an
entry, if it doesn't already exists, in a local database and passes entry, if it doesn't already exists, in a local database and passes
the FEC Framework configuration information from the SAP Payload the FEC Framework configuration information from the SAP Payload
field to the 'FEC Framework' module. When the same annoucement field to the 'FEC Framework' module. When the same annoucement
(please see section 5 of RFC2974) is received the next time, the (please see section 5 of RFC2974) is received the next time, the
timer of the corresponding entry should be reset to the three times timer of the corresponding entry should be reset to the three times
the time-interval value that is signaled by the sender or one hour, the time-interval value that is signaled by the sender or one hour,
whichever is greater. whichever is greater.
Editor's Note: SAP doesn't allow the time-interval to be signaled in Editor's Note: Unfortunately, SAP doesn't allow the time-interval to
the SAP header. Hence, we need this to be specified in the FEC be signaled in the SAP header. Hence, the time-interval should be
Framework Configuration Information (allowed by SAP). For example, specified in the FEC Framework Configuration Information. For
the usage of "r=" (repeat time) field in SDP. example, the usage of "r=" (repeat time) field in SDP.
The receiver, upon receiving a SAP delete message, must delete the The receiver, upon receiving a SAP delete message, must delete the
matching SAP entry in its database. This should result in the matching SAP entry in its database. This should result in the
receiver no longer using the relevant FEC framework configuration receiver no longer using the relevant FEC framework configuration
information for every instance, and should no longer subscribe to any information for every instance, and should no longer subscribe to any
related FEC streams. related FEC streams.
4.2. Signaling Protocol for Unicasting 4.2. Signaling Protocol for Unicasting
The signaling protocol for unicasting enables two nodes, which wish This document describes leveraging any signaling protocol that is
to communicate one-to-one across an IP network, to exchange the FEC already used by the unicast application, for exchanging the FEC
Framework configuration Information. This exchange may be Framework configuration Information between two nodes.
unidirectional or bidirectional depending on the application desiring
the FEC protection for its communication.
For example, a multimedia (VoD) client may send a request via For example, a multimedia (VoD) client may send a request via
unicasting for a particular content to the multimedia (VoD) server, unicasting for a particular content to the multimedia (VoD) server,
which may offer various options such as encodings, bitrates, which may offer various options such as encodings, bitrates,
transport etc. for the content. The client selects the suitable transport etc. for the content. The client selects the suitable
options and answers to the server, paving the way for the content to options and answers to the server, paving the way for the content to
be unicasted on the chosen transport from server to the client. This be unicasted on the chosen transport from server to the client. This
offer/answer signaling, described in [RFC3264], is commonly utilized offer/answer signaling, described in [RFC3264], is commonly utilized
by many application protocols such as SIP, RTSP etc. by many application protocols such as SIP, RTSP etc.
The fact that two nodes desiring unicast communication almost always The fact that two nodes desiring unicast communication almost always
rely on an application to first exchange the application related rely on an application to first exchange the application related
parameters via the signaling protocol, it is logical to enhance such parameters via the signaling protocol, it is logical to enhance such
signaling protocol(s) to (a) convey the desire for the FEC protection signaling protocol(s) to (a) convey the desire for the FEC protection
and (b) subsequently also exchange FEC parameters i.e. FEC Framework and (b) subsequently also exchange FEC parameters i.e. FEC Framework
Configuration information. This enables the node acting as the Configuration information. This enables the node acting as the
offerer to offer 'FEC Framework Configuration Information' for each offerer to offer 'FEC Framework Configuration Information' for each
of available FEC instances, and the node acting as the answerer of available FEC instances, and the node acting as the answerer
conveying the chosen FEC Framework instance(s) to the offerer. The conveying the chosen FEC Framework instance(s) to the offerer. The
usage of FEC framework instance i.e. FEC scheme is beyond the scope usage of FEC framework instance i.e. FEC scheme is explained the FEC
of this document. Please refer to the FEC Framework document Framework document [FECARCH].
[FECARCH].
While enhancing the application's signaling protocol to exchange FEC While enhancing anapplication's signaling protocol to exchange FEC
parameters is one method (briefly explained above), another method parameters is one method (briefly explained above), another method
would be to have a unicast based generic protocol that could be used would be to have a unicast based generic protocol that could be used
by two nodes independent of the application's signaling protocol. The by two nodes independent of the application's signaling protocol. The
latter method is under investigation and may be covered in future. latter method is under investigation and may be covered by a separate
document.
The remainder of this section provides example signaling protocols
and explains how they can be used to exchange FEC Framework
Configuration information.
4.2.1. SIP 4.2.1. SIP
SIP [RFC3261] is an application-level signaling protocol to create, SIP [RFC3261] is an application-level signaling protocol to create,
modify, and terminate multimedia sessions with one or more modify, and terminate multimedia sessions with one or more
participants. SIP also enables the participants to discover one participants. SIP also enables the participants to discover one
another and to agree on a characterization of a multimedia session another and to agree on a characterization of a multimedia session
they would like to share. SIP runs on either TCP or UDP or SCTP they would like to share. SIP runs on either TCP or UDP or SCTP
transport, and uses SDP to describe multmedia session attributes. transport, and uses SDP as the encoding format to describe multmedia
session attributes.
SIP already uses offer/answer model with SDP, described in [RFC3264], SIP already uses offer/answer model with SDP, described in [RFC3264],
to exchange the information between two nodes to establish unicast to exchange the information between two nodes to establish unicast
sessions between them. This specification extends the usage of this sessions between them. This document extends the usage of this model
model for exchanging the FEC Framework Configuration Information, for exchanging the FEC Framework Configuration Information, explained
explained in section 3, between two SIP speaking nodes. in section 3. Any SDP specific enhancements to accommodate the FEC
Framework are covered in the SDP Elements specification [FECSDP].
4.2.2. RSTP 4.2.2. RSTP
RTSP [RFC2326] is an application-level signaling protocol for control RTSP [RFC2326] is an application-level signaling protocol for control
over the delivery of data with real-time properties. RTSP provides an over the delivery of data with real-time properties. RTSP provides an
extensible framework to enable controlled, on-demand delivery of extensible framework to enable controlled, on-demand delivery of
real-time data, such as audio and video. RTSP runs on either TCP or real-time data, such as audio and video. RTSP runs on either TCP or
UDP transports. UDP transports.
RTSP already provides an ability to extend the existing method with RTSP already provides an ability to extend the existing method with
new parameters. This specification suggests requesting for the FEC new parameters. This specification suggests requesting for the FEC
protection options by including "FEC Protection Required" in the protection options by including "FEC Protection Required" in the
"Require:" header of SETUP (method) request message. The node "Require:" header of SETUP (method) request message. The node
receiving such request either responds with "200 OK" message that receiving such request either responds with "200 OK" message that
includes offers i.e. available FEC options (e.g. FEC Framework includes offers i.e. available FEC options (e.g. FEC Framework
Configuration Information for each Instnace) or "551 Option not Configuration Information for each Instnace) or "551 Option not
supported" message. A sample of related message exchange is shown supported" message. A sample of related message exchange is shown
below - below -
Node1->Node2: SETUP < . . .> RTSP/1.0 Node1->Node2: SETUP < . . .> RTSP/1.0
Cseq: 1 CSeq: 1
Transport: <omitted for simplicity> Transport: <omitted for simplicity>
Require: FEC Protections Required Require: FEC Protections Required
Node2->Node1: RTSP/1.0 200 OK Node2->Node1: RTSP/1.0 200 OK
Cseq: 1 CSeq: 1
Transport: <omitted for simplicity>
OR
Node2->Node1: RTSP/1.0 551 Option Not supported
Cseq: 1
Transport: <omitted for simplicity> Transport: <omitted for simplicity>
The requesting node (Node1) may then send either the SETUP message The requesting node (Node1) may then send either the SETUP message
without using the Require: header, if the remote node didn't support without using the Require: header, if the remote node didn't support
the "FEC protection", or a new SETUP message to request the selected the "FEC protection", or a new SETUP message to request the selected
FEC protection streams. FEC protection streams.
4.2.3. DSM-CC 4.2.3. DSM-CC
DSM-CC is a predominant suite of protocols including the signaling DSM-CC is a predominant suite of protocols including the signaling
protocol used for the video control plane in Cable/MSO networks that protocol used for the video control plane in Cable/MSO networks that
have offered video services for decades. Unfortunately, DSM-CC is have offered video services for decades. DSM-CC is standardised in
actually standardised in MPEG-2 ISO/IEC 13818-6 (part 6 of the MPEG-2 MPEG-2 ISO/IEC 13818-6 (part 6 of the MPEG-2 standard), not within
standard), not within the IETF yet, hence, DSM-CC related the IETF yet, hence, DSM-CC related enhancements aren't covered in
enhancements aren't covered in this document. The same is applicable this document. The same is applicable to Session Setup protocol (SSP)
to Session Setup protocol (SSP) and Lightweight Stream Control and Lightweight Stream Control Protocol (LSCP) that are derived from
Protocol (LSCP) that are derived from DSM-CC, as well. DSM-CC, as well.
5. Security Considerations 5. Security Considerations
There are no additional security consideration other than what's There is no additional security consideration other than what's
already covered in RFC2974 for SAP, RFC2326 for RTSP, RFC3261 for SIP already covered in RFC2974 for SAP, RFC2326 for RTSP, RFC3261 for SIP
etc. etc.
6. IANA Considerations 6. IANA Considerations
None. None.
7. Conclusions 7. Conclusions
TBD. TBD.
8. Acknowledgments 8. Acknowledgments
Thanks to Colin Perkins for pointing out the issue with the time- Thanks to Colin Perkins for pointing out the issue with the time-
interval for the SAP messages. Additionally, many thanks to Mark interval for the SAP messages. Additionally, thanks to Mark Watson,
Watson, Ali Begen and Ulas Kozat for helping with this proposal. Ali Begen and Ulas Kozat for solidifying this proposal.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[FECARCH] Watson, M., "Forward Error Correction (FEC) Framework", [FECARCH] Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-01 (work in progress),, draft-ietf-fecframe-framework-03 (work in progress),
November 2007. October 2008.
[FECSDP] Begen, A., "SDP Elements for FEC Framework", draft-begen- [FECSDP] Begen, A., "SDP Elements for FEC Framework", draft-ietf-
fecframe-sdp-elements-00 (work in progress), November 11 fecframe-sdp-elements-01 (work in progress), July 14 2008.
2007.
9.2. Informative References 9.2. Informative References
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
 End of changes. 45 change blocks. 
134 lines changed or deleted 124 lines changed or added

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