draft-ietf-fecframe-config-signaling-04.txt   draft-ietf-fecframe-config-signaling-05.txt 
FECFRAME Working Group Rajiv Asati FECFRAME Working Group Rajiv Asati
Internet Draft Cisco Systems Internet Draft Cisco Systems
Intended status: Experimental Intended status: Proposed Standard
Expires: July 2011 Expires: July 2011
January 11, 2011 May 30, 2011
Methods to convey FEC Framework Configuration Information Methods to convey FEC Framework Configuration Information
draft-ietf-fecframe-config-signaling-04.txt draft-ietf-fecframe-config-signaling-05.txt
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 how to use existing signaling protocols to This document describes how to use existing signaling protocols to
determine and dynamically communicate the Configuration information determine and dynamically communicate the Configuration information
between sender(s) and receiver(s). between sender(s) and receiver(s).
Status of this Memo Status of this Memo
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference 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 July 11, 2011. This Internet-Draft will expire on July 30, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 31 skipping to change at page 6, line 31
of a particular FEC Framework instance and/or its implementation. of a particular FEC Framework instance 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 by examining the encoded octets themselves. be fixed, or derived by examining the encoded octets themselves.
For example, the initial octets may include some kind of length For example, the initial octets may include some kind of length
indication. indication.
Independent of what all encoding formats supported by an FEC scheme, Independent of the encoding formats supported by an FEC scheme, each
each instance of the FEC Framework MUST use a single encoding format instance of the FEC Framework MUST use a single encoding format to
to describe all of the configuration information associated with describe all of the configuration information associated with that
that instance. The signaling protocol specified in this document instance. The signaling protocol specified in this document SHOULD
SHOULD NOT validate the encoded information, though it may validate NOT validate the encoded information, though it may validate the
the syntax or length of the encoded information. syntax 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.
5. Signaling Protocol Usage 5. 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), and somehow made available at the (or on behalf of a sender), and somehow made available at the
receiver(s). While one may envision a static method to populate the receiver(s). While one may envision a static method to populate the
configuration information at both sender and receiver(s), it would configuration information at both sender and receiver(s), it would
not be optimal since it would (i) require the knowledge of every not be optimal since it would (a) require the knowledge of every
receiver in advance, (b) require the time and means to configure receiver in advance, (b) require the time and means to configure
each receiver and sender, and (c) increase the misconfiguration each receiver and sender, and (c) increase the misconfiguration
possibility. Hence, there is a benefit in using a dynamic method possibility. Hence, there is a benefit in using a dynamic method
i.e., signaling protocol to convey the configuration information i.e., signaling protocol to convey the configuration information
between sender and one or more receivers. between sender and one or more receivers.
Since the configuration information may be needed at a particular Since the configuration information may be needed at a particular
receiver versus many receivers (depending on the multimedia stream receiver versus many receivers (depending on the multimedia stream
being unicast e.g. Video on Demand, or multicast e.g. Broadcast or being unicast e.g. Video on Demand, or multicast e.g. Broadcast or
IPTV), we need two types of signaling protocols - one to deliver the IPTV), we need two types of signaling protocols - one to deliver the
skipping to change at page 7, line 28 skipping to change at page 7, line 28
unicasting (described in section 4.2). 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_Receiver11,12,13 via the multicast signaling protocol, whereas FEC_Receiver11,12,13 via the multicast signaling protocol, whereas
the FEC_Sender2 is serving only FEC_Receiver2 via the unicast the FEC_Sender2 is serving only FEC_Receiver2 via the unicast
signaling protocol. signaling protocol.
FEC_Sender2---------| |--------FEC_Receiver2 FEC_Sender2---------| |--------FEC_Receiver2
| | | |
FEC_Sender1-----IP/MPLS network FEC_Sender1-------IP/MPLS network
|-----------FEC_Receiver11 |-----------FEC_Receiver11
|-----------FEC_Receiver12 |-----------FEC_Receiver12
|-----------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 document 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.
5.1. Signaling Protocol for Multicasting 5.1. Signaling Protocol for Multicasting
This specification describes using Session Announcement Protocol This specification describes using Session Announcement Protocol
(SAP) version 2 [RFC2974] as the signaling protocol to multicast the (SAP) version 2 [RFC2974] as the signaling protocol to multicast the
configuration information from one sender to many receivers. The configuration information from one sender to many receivers. The
apparent advantage is that the server doesn't need to maintain any apparent advantage is that the server doesn't need to maintain any
state for any receiver using SAP. state for any receiver using SAP.
SAP messages are carried over UDP over IP with destination UDP
port being 9875 and source UDP port being any available number,
as described in RFC2974. The SAP message(s) SHOULD contain an
authentication header and MAY employ cryptography. One
cryptography method suggested by this specification is the usage
of Group Cryptography as specified in GDOI [RFC3547].
At the high level, a sender, acting as the SAP announcer, signals At the high level, a sender, acting as the SAP announcer, signals
the FEC Framework Configuration Information for each FEC Framework the 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 (as port and at least one well known multicast group IP address (as
explained in the section 4.1.1). This enables the receiver to explained in the section 4.1.1). This enables the receiver to
receive the SAP message(s) and obtains the FEC Framework receive the SAP message(s) and obtains the FEC Framework
Configuration Information for each FEC Framework Instance. Configuration Information for each FEC Framework Instance.
skipping to change at page 8, line 29 skipping to change at page 8, line 36
in the Internet' document [SAP-REQ] to know about the SAP in the Internet' document [SAP-REQ] to know about the SAP
limitations. limitations.
Using the configuration information, the receiver becomes aware of Using the configuration information, the receiver becomes aware of
available FEC protection options, corresponding multicast trees (S,G available FEC protection options, corresponding multicast trees (S,G
or *,G addresses) etc. The receiver may subsequently subscribe to or *,G addresses) etc. The receiver may subsequently subscribe to
one or more multicast trees to receive the FEC streams using out-of- one or more multicast trees to receive the FEC streams using out-of-
band multicasting techniques such as PIM [RFC4601]. This, however, band multicasting techniques such as PIM [RFC4601]. This, however,
is outside the scope of this document. is outside the scope of this document.
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 message(s) SHOULD contain an authentication header and MAY
employ cryptography. One cryptography method suggested by this
specification is the usage of Group Cryptography as specified in
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) -
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash | | V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: originating source (32 or 128 bits) : : originating source (32 or 128 bits) :
: : : :
skipping to change at page 10, line 33 skipping to change at page 10, line 33
- 224.2.127.254 (if IPv4 global scope 224.0.1.0-238.255.255.255 - 224.2.127.254 (if IPv4 global scope 224.0.1.0-238.255.255.255
is selected for the FEC stream), or is selected for the FEC stream), or
- FF0X:0:0:0:0:0:2:7FFE (if IPv6 multicasting is selected for the - FF0X:0:0:0:0:0:2:7FFE (if IPv6 multicasting is selected for the
FEC stream, where X is the 4-bit scope value), or FEC stream, where X is the 4-bit scope value), or
- the highest multicast address (239.255.255.255, for example) in - the highest multicast address (239.255.255.255, for example) in
the relevant administrative scope zone (if IPv4 administrative the relevant administrative scope zone (if IPv4 administrative
scope 239.0.0.0-239.255.255.255 is selected for the FEC stream) scope 239.0.0.0-239.255.255.255 is selected for the FEC stream)
The destination UDP port MUST be 9875 and source UDP port may be any As defined in RFC2974, the IP packet carrying SAP message MUST use
destination UDP port being 9875 and source UDP port bein any
available number. The default IP TTL value (or Hop Limit value) available number. The default IP TTL value (or Hop Limit value)
SHOULD be 255, though the implementation may allow it to be any SHOULD be 255 at the sender, though the sender implementation may
other value to implicitly create the multicast boundary for SAP allow it to be any other value to implicitly create the multicast
announcements. The IP DSCP field may be set to any value that boundary for SAP announcements. The IP DSCP field may be set to any
indicates a desired QoS treatment in the IP network. value that 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 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. message, 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 streams (i.e., source or repair flows), though it may use the same
IP address as the 'originating source' address to identify the FEC IP address as the 'originating source' address to identify the FEC
streams (i.e., source or repair flows). Please refer to IANA streams (i.e., source or repair flows). Please refer to IANA
assignments for multicast addresses. assignments for multicast addresses.
The sender MUST periodically send the 'SAP announcement' message to The sender MUST periodically send the 'SAP announcement' message to
ensure that the receiver doesn't purge the cached entry(s) from the ensure that the receiver doesn't purge the cached entry(s) from the
database and doesn't trigger the deletion of FEC Framework database and doesn't trigger the deletion of FEC Framework
Configuration Information. Configuration Information.
Please note that the deletion of FEC Framework Configuration
Information SHOULD NOT mean that the receiver stops its FEC
processing for the instance for which it had already got the
configuration information.
While the time interval between repetitions of an announcement can While the time interval between repetitions of an announcement can
be calculated as per the very sophisticated but complex method be calculated as per the very sophisticated but complex method
explained in [RFC2974], the preferred and simpler method recommended explained in [RFC2974], this document recommends a simpler method in
by this specification is to let the user specify the time interval which the user specifies the time interval in the range of 1-200
from the range of 1-200 seconds with suggested default being 60 seconds with suggested default value being 60 seconds. In this
seconds. The time interval MUST be chosen to ensure that SAP method, the 'time interval' may be signaled in the SAP message
announcement messages are sent out before the corresponding payload e.g. within the FEC Framework Configuration Information.
multicast routing entry e.g. (S,G) or (*,G) (corresponding to the
SAP multicast tree(s)) on the router times out. (It is worth noting
that the default time-out period for the multicast routing entry is
210 seconds, per the PIM specification [RFC4601], though the time-
out period may be set to another value as allowed by the router
implementation.)
The SAP implementation MAY also support the complex method for
determining the SAP announcement time interval, and provide the
option to select it over the simpler method.
When simpler method is used, the 'time interval' may be signaled in
the SAP message payload e.g. within the FEC Framework Configuration
Information.
Note that SAP doesn't allow the time-interval to be signaled in Note that SAP doesn't allow the time-interval to be signaled in
the SAP header. Hence, the usage of simpler method desires the the SAP header. Hence, the usage of simpler method desires the
time-interval to be included in the FEC Framework Configuration time-interval to be included in the FEC Framework Configuration
Information, if the default time interval (=60 seconds) for SAP Information, if the default time interval (=60 seconds) for SAP
message repeations is not deemed enough. For example, the usage of message repeations is not deemed enough. For example, the usage of
"r=" (repeat time) field in SDP to convey the time-interval value, "r=" (repeat time) field in SDP to convey the time-interval value,
if SDP encoding format is used. if SDP encoding format is used.
The time interval MUST be chosen to ensure that SAP announcement
messages are sent out before the corresponding multicast routing
entry e.g. (S,G) or (*,G) (corresponding to the SAP multicast
tree(s)) on the router(s) times out. (It is worth noting that the
default time-out period for the multicast routing entry is 210
seconds, per the PIM specification [RFC4601], though the time-out
period may be set to another value as allowed by the router
implementation.)
A SAP implementation MAY also support the complex method for
determining the SAP announcement time interval, and provide the
option to select it.
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
deletion may be useful if the sender no longer desires to send deletion is useful if the sender no longer desires to send anymore
anymore FEC streams. 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 sender MUST send a new announcement message with a different
'Message Identifier Hash' value as per the rules described in 'Message Identifier Hash' value as per the rules described in
section 5 of RFC2974 [RFC2974]. Such announcement message SHOULD be section 5 of RFC2974 [RFC2974]. Such announcement message SHOULD be
sent immediately (without having to wait for the time-interval) to sent immediately (without having to wait for the time-interval) to
ensure that the modifications are received by the receiver as soon ensure that the modifications are received by the receiver as soon
as possible. The sender MUST also send the SAP deletion message to as possible. The sender MUST also send the SAP deletion message to
delete the previous SAP announcement message (i.e., with the delete the previous SAP announcement message (i.e., with the
skipping to change at page 12, line 39 skipping to change at page 12, line 33
value, which is either the default = 60 seconds, or the value value, which is either the default = 60 seconds, or the value
signaled by the sender. signaled by the sender.
Note that SAP doesn't allow the time-interval to be signaled in Note that SAP doesn't allow the time-interval to be signaled in
the SAP header. Hence, the time-interval SHOULD be included in the the SAP header. Hence, the time-interval SHOULD be included in the
FEC Framework Configuration Information. For example, the usage of FEC Framework Configuration Information. For example, the usage of
"r=" (repeat time) field in SDP to convey the time-interval value, "r=" (repeat time) field in SDP to convey the time-interval value,
if SDP encoding format is used. if SDP encoding format is used.
The time-out value associated with each entry is reset when the The time-out value associated with each entry is reset when the
corresponding annoucement (please see section 5 of [RFC2974]) is corresponding announcement (please see section 5 of [RFC2974]) is
received. If the time-out value for any entry reaches zero, then the received. If the time-out value for any entry reaches zero, then
entry is deleted from the database. that entry MUST be deleted from the database.
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.
receiver no longer using the relevant FEC Framework Configuration
Information for the corresponding instance, and SHOULD no longer The deletion of SAP entry MUST result in the receiver no longer
subscribe to any related FEC streams. using the relevant FEC Framework Configuration Information for the
corresponding instance, and MUST no longer subscribe to any related
FEC streams.
5.2. Signaling Protocol for Unicasting 5.2. Signaling Protocol for Unicasting
This document describes leveraging any signaling protocol that is This document describes leveraging any signaling protocol that is
already used by the unicast application, for exchanging the FEC already used by the unicast application, for exchanging the FEC
Framework Configuration Information between two nodes. Framework Configuration Information between two nodes.
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,
skipping to change at page 13, line 33 skipping to change at page 13, line 33
signaling protocol(s) to (a) convey the desire for the FEC signaling protocol(s) to (a) convey the desire for the FEC
protection and (b) subsequently also exchange FEC parameters i.e., protection and (b) subsequently also exchange FEC parameters i.e.,
FEC Framework Configuration Information. This enables the node FEC Framework Configuration Information. This enables the node
acting as the offerer to offer 'FEC Framework Configuration acting as the offerer to offer 'FEC Framework Configuration
Information' for each of available FEC instances, and the node Information' for each of available FEC instances, and the node
acting as the answerer conveying the chosen FEC Framework acting as the answerer conveying the chosen FEC Framework
instance(s) to the offerer. The usage of FEC framework instance is instance(s) to the offerer. The usage of FEC framework instance is
explained the FEC Framework document [FECARCH]. explained the FEC Framework document [FECARCH].
While enhancing an application's signaling protocol to exchange FEC While enhancing an application's signaling protocol to exchange FEC
parameters is one method (briefly explained above), another method parameters is one method (briefly explained above), an alternative
would be to have a unicast based generic protocol that could be used method would be to have a unicast based generic protocol that could
by two nodes independent of the application's signaling protocol. be used by two nodes independent of the application's signaling
The latter method is under investigation and may be covered by a protocol. The latter is not covered by this document, of course.
separate document.
The remainder of this section provides example signaling protocols The remainder of this section provides example signaling protocols
and explains how they can be used to exchange FEC Framework and explains how they can be used to exchange FEC Framework
Configuration Information. Configuration Information.
5.2.1. SIP 5.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
skipping to change at page 14, line 17 skipping to change at page 14, line 15
session attributes. session attributes.
SIP already uses an offer/answer model with SDP, described in SIP already uses an offer/answer model with SDP, described in
[RFC3264], to exchange the information between two nodes to [RFC3264], to exchange the information between two nodes to
establish unicast sessions between them. This document extends the establish unicast sessions between them. This document extends the
usage of this model for exchanging the FEC Framework Configuration usage of this model for exchanging the FEC Framework Configuration
Information, explained in section 3. Any SDP specific enhancements Information, explained in section 3. Any SDP specific enhancements
to accommodate the FEC Framework are covered in the SDP Elements to accommodate the FEC Framework are covered in the SDP Elements
specification [FECSDP]. specification [FECSDP].
5.2.2. RSTP 5.2.2. RTSP
RTSP [RFC2326] is an application-level signaling protocol for Real-Time Streaming Protocol (RTSP) [RFC2326] is an application-
control over the delivery of data with real-time properties. RTSP level signaling protocol for control over the delivery of data with
provides an extensible framework to enable controlled, on-demand real-time properties. RTSP provides an extensible framework to
delivery of real-time data, such as audio and video. RTSP runs on enable controlled, on-demand delivery of real-time data, such as
either TCP or UDP transports. audio and video. RTSP runs on either TCP or 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 defines 'FEC Protection Required' new parameters. This specification defines 'FEC Protection Required'
option-tag (please see section 6 for IANA Considerations) and option-tag (please see section 6 for IANA Considerations) and
prescribes including it in the Require (or Proxy-Require) header of prescribes including it in the Require (or Proxy-Require) header of
SETUP (method) request message, so as to request for FEC protection SETUP (method) request message, so as to request for FEC protection
for the data. for the data.
The node receiving such request either responds with "200 OK" The node receiving such request either responds with "200 OK"
message that includes offers i.e., available FEC options (e.g. FEC message that includes offers i.e., available FEC options (e.g. FEC
skipping to change at page 15, line 25 skipping to change at page 15, line 25
This document recommends SAP message(s) be authenticated to ensure This document recommends SAP message(s) be authenticated to ensure
sender authentication, as described in section 5. sender authentication, as described in section 5.
There is 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, and already covered in [RFC2974] for SAP, [RFC2326] for RTSP, and
[RFC3261] for SIP. [RFC3261] for SIP.
7. IANA Considerations 7. IANA Considerations
This document requests IANA to register a new option-tag for FEC This document requests IANA to register a new option-tag for FEC
protection required, as described in section 4.2.2, and provides the protection required, as described in section 5.2.2 earlier, and
following information in compliance with section 3.8.1 in [RFC2326]: provides the following information in compliance with section 3.8.1
in [RFC2326]:
. Name of option = FECprotectionRequired . Name of option = FECprotectionRequired
. Change of Control = IETF . Change of Control = IETF
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, thanks to Vincent Roca, interval for the SAP messages. Additionally, thanks to Vincent Roca,
Ali Begen, Mark Watson and Ulas Kozat for greatly improving this Ali Begen, Mark Watson and Ulas Kozat for greatly improving this
 End of changes. 22 change blocks. 
72 lines changed or deleted 69 lines changed or added

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