draft-ietf-fecframe-config-signaling-09.txt   rfc6695.txt 
FECFRAME Working Group Rajiv Asati
Internet Draft Cisco Systems
Intended status: Informational
Expires: July 2012
June 8, 2012 Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 6695 Cisco Systems
Category: Informational August 2012
ISSN: 2070-1721
Methods to convey FEC Framework Configuration Information Methods to Convey Forward Error Correction (FEC)
draft-ietf-fecframe-config-signaling-09.txt Framework Configuration Information
Abstract Abstract
FEC Framework document [RFC6363] defines the FEC Framework The Forward Error Correction (FEC) Framework document (RFC 6363)
Configuration Information necessary for the FEC framework operation. defines the FEC Framework Configuration Information necessary for the
This document describes how to use signaling protocols such as FEC Framework operation. This document describes how to use
Session Announcement Protocol (SAP), Session Initiation Protocol signaling protocols such as the Session Announcement Protocol (SAP),
(SIP), Real Time Stream Protocol (RTSP) etc. for determining and the Session Initiation Protocol (SIP), the Real Time Streaming
communicating the Configuration information between sender(s) and Protocol (RTSP), etc. for determining and communicating the
receiver(s). configuration information between sender(s) and receiver(s).
This document doesn't define any new signaling protocol. This document doesn't define any new signaling protocol.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on November 8, 2012. 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/rfc6695.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ....................................................2
2. Specification Language.........................................4 2. Specification Language ..........................................3
3. Terminology/Abbreviations......................................4 3. Terminology/Abbreviations .......................................3
4. FEC Framework Configuration Information........................5 4. FEC Framework Configuration Information .........................4
4.1. Encoding Format...........................................6 4.1. Encoding Format ............................................5
5. Signaling Protocol Usage.......................................7 5. Signaling Protocol Usage ........................................6
5.1. Signaling Protocol for Multicasting.......................8 5.1. Signaling Protocol for Multicasting ........................7
5.1.1. Sender Procedure.....................................9 5.1.1. Sender Procedure ....................................9
5.1.2. Receiver Procedure..................................12 5.1.2. Receiver Procedure .................................11
5.2. Signaling Protocol for Unicasting........................13 5.2. Signaling Protocol for Unicasting .........................12
5.2.1. SIP.................................................13 5.2.1. SIP ................................................12
5.2.2. RTSP................................................14 5.2.2. RTSP ...............................................13
6. Security Considerations.......................................15 6. Security Considerations ........................................14
7. IANA Considerations...........................................15 7. IANA Considerations ............................................14
8. Acknowledgments...............................................15 8. Acknowledgments ................................................14
9. References....................................................16 9. References .....................................................14
9.1. Normative References.....................................16 9.1. Normative References ......................................14
9.2. Informative References...................................16 9.2. Informative References ....................................15
Author's Addresses...............................................17
1. Introduction 1. Introduction
FEC Framework document [RFC6363] defines the FEC Framework The FEC Framework document [RFC6363] 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). available at both the sender and receiver(s).
This document describes how various signaling protocols such as This document describes how various signaling protocols such as the
Session Announcement Protocol (SAP)[RFC2974], Session Initiation Session Announcement Protocol (SAP) [RFC2974], the Session Initiation
Protocol (SIP)[RFC3261], Real Time Stream Protocol (RTSP)[RFC2326] Protocol (SIP) [RFC3261], the Real Time Streaming Protocol (RTSP)
etc. could be used by the FEC scheme (and/or Content Delivery [RFC2326], etc. could be used by the FEC scheme (and/or the Content
Protocol (CDP))to communicate the Configuration information between Delivery Protocol (CDP)) to communicate the configuration information
sender and receiver(s). The configuration information may be encoded between the sender and receiver(s). The configuration information
in any compatible format such as SDP [RFC4566], XML etc., though may be encoded in any compatible format, such as the Session
this document references to SDP encoding usage quite extensively. Description Protocol (SDP) [RFC4566], XML, etc., though this document
refers to SDP encoding usage quite extensively.
Note that this document doesn't define any new signaling protocol; Note that this document doesn't define any new signaling protocol;
rather it just provides examples of how existing protocols should rather, it just provides examples of how existing protocols should
be used. Also, the list of signaling protocols for unicast is not be used. Also, the list of signaling protocols for unicast is not
intended to be a complete list. intended to be a complete list.
This document doesn't describe any FEC scheme specific information This document doesn't describe any FEC-Scheme-Specific Information
(FSSI) (for example, how source blocks are constructed) or any (FSSI) (for example, how source blocks are constructed) or any
sender or receiver side operation for a particular FEC scheme (for sender- or receiver-side operation for a particular FEC scheme (for
example, whether the receiver makes use of one or more repair flows example, whether the receiver makes use of one or more repair flows
that are received). Such FEC scheme specifics should be covered in that are received). 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.
This document is structured such that Section 2 describes the terms This document is structured as follows: Section 3 describes the terms
used in this document, section 4 describes the FEC Framework used in this document, Section 4 describes the FEC Framework
Configuration Information, section 5 describes how to use signaling Configuration Information, Section 5 describes how to use signaling
protocol for the multicast and unicast applications, and section 6 protocols for multicast and unicast applications, and Section 6
describes security consideration. discusses security considerations.
2. Specification Language 2. Specification Language
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].
3. Terminology/Abbreviations 3. Terminology/Abbreviations
This document makes use of the terms/abbreviations defined in the
FEC Framework document [RFC6363] and defines the following
additional terms:
o Media Sender - Node providing original media flow(s) to the This document makes use of the terms/abbreviations defined in the FEC
'FEC Sender' Framework document [RFC6363] and defines the following additional
terms:
o Media Receiver - Node performing the Media decoding; o Media Sender - Node providing original media flow(s) to the 'FEC
Sender'
o FEC Sender - Node performing the FEC encoding on the o Media Receiver - Node performing the media decoding
original media flow(s) to produce the FEC repair flow(s)
o FEC Receiver - Node performing the FEC decoding, as needed, o FEC Sender - Node performing the FEC encoding on the original
and providing the original media flow(s) to the Media receiver. media flow(s) to produce the FEC repair flow(s)
o Sender - Same as FEC Sender o FEC Receiver - Node performing the FEC decoding, as needed, and
providing the original media flow(s) to the Media Receiver
o Receiver - Same as FEC Receiver o Sender - Same as FEC Sender
o Receiver - Same as FEC Receiver
o (Media) Flow - A single media instance i.e., an audio stream o (Media) Flow - A single media instance, i.e., an audio stream or a
or a video stream. video stream
This document 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.
4. FEC Framework Configuration Information 4. FEC Framework Configuration Information
The FEC Framework [RFC6363] defines a minimum set of information The FEC Framework [RFC6363] defines a minimum set of information that
that is communicated between the sender and receiver(s) for a proper is 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.
A single instance of the FEC Framework provides FEC protection for A single instance of the FEC Framework provides FEC protection for
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 one or more packet flows consisting of repair packets. As per
FEC Framework document [RFC6363] section 6.5, the FEC Framework Section 5.5 of the FEC Framework document [RFC6363], the FEC
Configuration Information includes the following for each FEC Framework Configuration Information includes the following for each
Framework instance: FEC Framework instance:
1. Identification of the repair flow(s) 1. Identification of the repair flow(s)
2. Identification of Source Flow(s) 2. Identification of source flow(s)
3. Identification of FEC Scheme 3. Identification of FEC scheme
4. Length of Explicit Source FEC payload ID 4. Length of Explicit Source FEC Payload ID
5. FEC Scheme Specific Information (FSSI) 5. 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 [RFC6363] wait-time, etc. Please refer to the FEC Framework document [RFC6363]
for more details. for more details.
The usage of signaling protocols described in this document requires The usage of signaling protocols described in this document requires
that the application layer responsible for the FEC Framework that the application layer responsible for the FEC Framework instance
instance provide the value for each of the configuration information provide the value for each of the configuration information
parameter (listed above) encoded as per the chosen encoding format. parameters (listed above) encoded as per the chosen encoding format.
In case of failure to receive the complete information, the In case of failure to receive the complete information, the signaling
signaling protocol module must return an error for the Operation, protocol module must return an error for Operations, Administration,
Administration and Maintenance (OAM) purposes and optionally convey and Maintenance (OAM) purposes and optionally convey this error to
this error to the application layer. Please refer to the figure 1 of the application layer. Please refer to Figure 1 of the FEC Framework
the FEC Framework document [RFC6363] for further illustration. document [RFC6363] 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
'Media Sender' functionalities are implemented on the same device, 'Media Sender' functionalities are implemented on the same device,
though that may be the case. Similarly, this document does not make though that may be the case. Similarly, this document does not make
any assumption that 'FEC receiver' and 'Media Receiver' any assumption that 'FEC Receiver' and 'Media Receiver'
functionalities are implemented on the same device, though that may functionalities are implemented on the same device, though that may
be the case. There may also be more than one Media Sender. be the case. There may also be more than one Media Sender.
4.1. Encoding Format 4.1. Encoding Format
The FEC Framework Configuration Information (listed above in section The FEC Framework Configuration Information (listed above in
4) may be encoded in any format such as SDP, XML etc. as chosen or Section 4) may be encoded in any format, such as SDP, XML, etc., as
prefered by a particular FEC Framework instance. The selection of chosen or preferred by a particular FEC Framework instance. The
such encoding format or syntax is independent of the signaling selection of such encoding formats or syntax is independent of the
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 Any encoding format that is selected for a particular FEC Framework
instance, it must be known to the signaling protocol. This is to instance must be known to the signaling protocol. This is to provide
provide a means (e.g. a field such as Payload Type) in the signaling a means (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 at the receiver. Please note that the chosen encoding format at the receiver. Please note that the
encoding format is not a negotiated parameter, but rather a property encoding format is not a negotiated parameter, but rather a property
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 be 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 the encoding formats supported by an FEC scheme, each Independent of the encoding formats supported by an FEC scheme, each
instance of the FEC Framework must use a single encoding format to instance of the FEC Framework must use a single encoding format to
describe all of the configuration information associated with that describe all of the configuration information associated with that
instance. The signaling protocol specified in this document should instance. The signaling protocol specified in this document should
not validate the encoded information, though it may validate the not validate the encoded information, though it may validate the
syntax or length of the encoded information. syntax or length of the encoded information.
The reader may refer to the SDP elements document [RFC6364], which The reader may refer to the SDP elements document [RFC6364], which
describes the usage of 'SDP' encoding format as an example encoding describes the usage of the 'SDP' encoding format as an example
format for FEC Framework Configuration Information. encoding format for the FEC Framework Configuration Information.
5. Signaling Protocol Usage 5. Signaling Protocol Usage
FEC Framework [RFC6363] requires certain FEC Framework Configuration The FEC Framework [RFC6363] requires that certain FEC Framework
Information to be available to both sender and receiver(s). This Configuration Information be available to both the sender and
configuration information is almost always formulated at the sender receiver(s). This configuration information is almost always
(or on behalf of a sender), and somehow made available at the formulated at the sender (or on behalf of the sender) and somehow
receiver(s). While one may envision a static method to populate the made available at the receiver(s). While one may envision a static
configuration information at both sender and receiver(s), it would method to populate the configuration information at both the sender
not be optimal since it would (a) require the knowledge of every and receiver(s), it would not be optimal, since it would (a) require
receiver in advance, (b) require the time and means to configure the knowledge of every receiver in advance, (b) require the time and
each receiver and sender, and (c) increase the misconfiguration means to configure each receiver and sender, and (c) increase the
possibility. Hence, there is a benefit in using a dynamic method possibility of misconfiguration. Hence, there is a benefit in using
i.e., signaling protocol to convey the configuration information a dynamic method (i.e., signaling protocol) to convey the
between sender and one or more receivers. configuration information between the 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 (VoD); or multicast, e.g.,
IPTV), we need two types of signaling protocols - one to deliver the broadcast or IPTV), we need two types of signaling protocols -- one
configuration information to many receivers via multicasting to deliver the configuration information to many receivers via
(described in section 5.1), and the other to deliver the multicasting (as described in Section 5.1), and the other to deliver
configuration information to one and only one receiver via the configuration information to one and only one receiver via
unicasting (described in section 5.2). unicasting (as described in Section 5.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 (which 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, FEC_Receiver12, and FEC_Receiver13 via the multicast
the FEC_Sender2 is serving only FEC_Receiver2 via the unicast signaling protocol, whereas FEC_Sender2 is serving only FEC_Receiver2
signaling protocol. via the unicast 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 document 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 SAP version 2 [RFC2974] as the
(SAP) version 2 [RFC2974] as the signaling protocol to multicast the signaling protocol to multicast the configuration information from
configuration information from one sender to many receivers. The one sender to many receivers. The apparent advantage is that the
apparent advantage is that the server doesn't need to maintain any 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 SAP messages are carried over UDP over IP with destination UDP
port being 9875 and source UDP port being any available number, port 9875, as described in [RFC2974], and a source UDP port of any
as described in RFC2974. The SAP message(s) MUST contain an available number. The SAP message(s) MUST contain an
authentication header using PGP authentication. authentication header using Pretty Good Privacy (PGP)
authentication.
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
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
section 4.1, is carried in the Payload of the SAP message(s). A Section 4.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 5.1.1). This enables the receiver to explained in Section 5.1.1). This enables the receiver to receive
receive the SAP message(s) and obtains the FEC Framework the SAP message(s) and obtain the FEC Framework Configuration
Configuration Information for each FEC Framework Instance. Information for each FEC Framework instance.
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.
Figure 2 below illustrates the SAP packet format (it is reprinted Figure 2 below (reprinted from [RFC2974]) illustrates the SAP packet
from the RFC2974) - format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 SAP Message format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
While the RFC2974 includes explanation for each field, it is worth Figure 2. SAP Message Format
discussing the 'Payload' and 'Payload Type' fields. The 'Payload'
While [RFC2974] includes explanations for each field, it is worth
discussing the 'Payload' and 'Payload Type' fields. The 'Payload'
field is used to carry the FEC Framework Configuration Information. field is used to carry the FEC Framework Configuration Information.
Subsequently, the optional 'Payload Type' field, which is a MIME Subsequently, the optional 'Payload Type' field, which is a MIME
content type specifier, is used to describe the encoding format used content type specifier, is used to describe the encoding format used
to encode the Payload. to encode the payload.
For example, the 'Payload Type' field may be application/sdp if For example, the 'Payload Type' field may be application/sdp if
the FEC Framework Configuration Information is encoded in SDP the FEC Framework Configuration Information is encoded in SDP
format and carried in the SAP payload. Similarly, it would be format and carried in the SAP payload. Similarly, it would be
application/xml if the FEC Framework Configuration Information was application/xml if the FEC Framework Configuration Information
encoded in XML format. were encoded in XML format.
Section 5.1.1 describes the sender procedure, whereas the section Section 5.1.1 describes the sender procedure, whereas Section 5.1.2
5.1.2 describes the receiver procedure in the context of config describes the receiver procedure in the context of config signaling
signaling using RFC2974. using [RFC2974].
5.1.1. Sender Procedure 5.1.1. Sender Procedure
The sender signals the FEC framework configuration for each FEC The sender signals the FEC Framework Configuration Information for
framework instance in a periodic SAP announcement message [RFC2974]. each FEC Framework instance in a periodic SAP announcement message
The SAP announcement message is sent to a well known multicast IP [RFC2974]. The SAP announcement message is sent to a well-known
address and UDP port, as specified in [RFC2974]. The announcement is multicast IP address and UDP port, as specified in [RFC2974]. The
multicast with the same scope as the session being announced. announcement is multicast with the same scope as the 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 must carry the FEC Framework Configuration Information for a message must carry the FEC Framework Configuration Information for a
single FEC Framework Instance. The SAP message is then sent over UDP single FEC Framework instance. The SAP message is then sent over UDP
over IP. over IP.
While it is possible to aggregate multiple SAP (announcement) While it is possible to aggregate multiple 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,
this specification does not recommend it since there is no length this specification does not recommend it, since there is no length
field in the SAP header to identify SAP message boundary. Hence, field in the SAP header to identify a SAP message boundary.
this specification recommends single SAP announcement message to Hence, this specification recommends that a single SAP
be sent in a UDP datagram. announcement message be sent in a UDP datagram.
The IP packet carrying the SAP message must be sent to destination The IP packet carrying the SAP message must be sent to a destination
IP address of one of the following depending on the selected scope: IP address of one of the following, depending on the selected scope:
- 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
is selected for the FEC stream), or 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
FEC stream, where X is the 4-bit scope value), or 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
the relevant administrative scope zone (if IPv4 administrative relevant administrative scope zone (if IPv4 administrative scope
scope 239.0.0.0-239.255.255.255 is selected for the FEC stream) 239.0.0.0-239.255.255.255 is selected for the FEC stream)
As defined in RFC2974, the IP packet carrying SAP message must use As defined in [RFC2974], the IP packet carrying a SAP message must
destination UDP port being 9875 and source UDP port bein any use destination UDP port 9875 and a source UDP port of any available
available number. The default IP TTL value (or Hop Limit value) number. The default IP Time to Live (TTL) value (or Hop Limit value)
should be 255 at the sender, though the sender implementation may should be 255 at the sender, though the sender implementation may
allow it to be any other value to implicitly create the multicast allow it to be any other value to implicitly create the multicast
boundary for SAP announcements. The IP DSCP field may be set to any boundary for SAP announcements. The IP Differentiated Services Code
value that indicates a desired QoS treatment in the IP network. Point (DSCP) field may be set to any 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 a 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
message, as the one used in the source IP address of the IP packet. as that 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
IP address as the 'originating source' address to identify the FEC 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 or entries
database and doesn't trigger the deletion of FEC Framework from the database and doesn't trigger the deletion of the FEC
Configuration Information. Framework Configuration Information.
While the time interval between repetitions of an announcement can While the time interval between repetitions of an announcement can be
be calculated as per the very sophisticated but complex method calculated as per the very sophisticated but complex method explained
explained in [RFC2974], this document recommends a simpler method in in [RFC2974], this document recommends a simpler method in which the
which the user specifies the time interval in the range of 1-200 user specifies the time interval in the range of 1-200 seconds, with
seconds with suggested default value being 60 seconds. In this a suggested default value of 60 seconds. In this method, the 'time
method, the 'time interval' may be signaled in the SAP message interval' may be signaled in the SAP message payload, e.g., within
payload e.g. within the FEC Framework Configuration Information. 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 requires the the SAP header. Hence, the usage of a simpler method requires
time-interval to be included in the FEC Framework Configuration that the time interval be included in the FEC Framework
Information, if the default time interval (=60 seconds) for SAP Configuration Information if the default time interval (60
message repeations is not used. For example, the usage of "r=" seconds) for SAP message repetitions is not used. For example,
(repeat time) field in SDP may convey the time-interval value, if the usage of the 'r=' (repeat time) field in SDP may convey the
SDP encoding format is used. time interval value if the SDP encoding format is used.
The time interval must be chosen to ensure that SAP announcement The time interval must be chosen to ensure that SAP announcement
messages are sent out before the corresponding multicast routing messages are sent out before the corresponding multicast routing
entry e.g. (S,G) or (*,G) (corresponding to the SAP multicast 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 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 default timeout period for the multicast routing entry is
seconds, per the PIM specification [RFC4601], though the time-out 210 seconds, per the PIM specification [RFC4601], though the timeout
period may be set to another value as allowed by the router period may be set to another value as allowed by the router
implementation.) implementation.)
A SAP implementation may also support the complex method for A SAP implementation may also support the complex method for
determining the SAP announcement time interval, and provide the determining the SAP announcement time interval and provide the
option to select it. 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, as defined in section 4 of RFC2974. The Configuration Information, as defined in Section 4 of [RFC2974]. The
explicit deletion is useful if the sender no longer desires to send explicit deletion is useful if the sender no longer desires to send
anymore FEC streams. any more 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
'Message Identifier Hash' value as per the rules described in Identifier Hash' value as per the rules described in Section 5 of
section 5 of RFC2974 [RFC2974]. Such announcement message should be RFC 2974 [RFC2974]. Such an announcement message should be sent
sent immediately (without having to wait for the time-interval) to immediately (without having to wait for the time interval) to ensure
ensure that the modifications are received by the receiver as soon that the modifications are received by the receiver as soon as
as possible. The sender must also send the SAP deletion message to 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 previous
previous 'Message Identifier Hash' value). 'Message Identifier Hash' value).
5.1.2. Receiver Procedure 5.1.2. Receiver Procedure
The receiver must listen on UDP port 9875 for packets arriving with The receiver must listen on UDP port 9875 for packets arriving with
IP destination address of either 224.2.127.254 (if IPv4 global scope an IP destination address of either 224.2.127.254 (if an IPv4 global
session is used for the FEC stream), or FF0X:0:0:0:0:0:2:7FFE (if scope session is used for the FEC stream), ff0x:0:0:0:0:0:2:7ffe (if
IPv6 is selected, where X is the 4-bit scope value), or the highest IPv6 is selected, where x is the 4-bit scope value), or the highest
IP address (239.255.255.255, for example) in the relevant IP address (239.255.255.255, for example) in the relevant
administrative scope zone (if IPv4 administrative scope 239.0.0.0- administrative scope zone (if IPv4 administrative scope 239.0.0.0-
239.255.255.255 is selected for the FEC stream). These IP addresses 239.255.255.255 is selected for the FEC stream). These IP addresses
are mandated for SAP usage by RFC2974 [RFC2974]. are mandated for SAP usage by RFC 2974 [RFC2974].
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 exist, in a local database and passes entry, if it doesn't already exist, 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. Each entry also maintains a field to the 'FEC Framework' module. Each entry also maintains a
time-out value, which is (re)set to five times the time-interval timeout value, which is (re)set to five times the time interval
value, which is either the default = 60 seconds, or the value value, which in turn is either the default of 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
FEC Framework Configuration Information. For example, the usage of the FEC Framework Configuration Information -- for example, the
"r=" (repeat time) field in SDP to convey the time-interval value, usage of the 'r=' (repeat time) field in SDP to convey the time
if SDP encoding format is used. interval value if the SDP encoding format is used.
The time-out value associated with each entry is reset when the The timeout value associated with each entry is reset when the
corresponding announcement (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 received. If the timeout value for any entry reaches zero, then that
that entry must be deleted from the database, as described in entry must be deleted from the database, as described in Section 4 of
section 4 of [RFC2974]. The receiver, upon receiving a SAP delete [RFC2974]. The receiver, upon receiving a SAP delete message, must
message, must delete the matching SAP entry in its database, as delete the matching SAP entry in its database, as described in
described in section 4 of [RFC2974]. Section 4 of [RFC2974].
The deletion of SAP entry must result in the receiver no longer The deletion of a SAP entry must result in the receiver no longer
using the relevant FEC Framework Configuration Information for the using the relevant FEC Framework Configuration Information for the
corresponding instance, and must no longer subscribe to any related corresponding instance and no longer subscribing to any related FEC
FEC streams. 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,
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 the server, paving the way for the content to be
be unicast on the chosen transport from server to the client. This unicast on the chosen transport from the 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 makes it logical to enhance parameters via the signaling protocol makes it logical to enhance
such signaling protocol(s) to (a) convey the desire for the FEC such 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 the 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 available FEC instance and the node acting as
acting as the answerer conveying the chosen FEC Framework the answerer to convey the chosen FEC Framework instance(s) to the
instance(s) to the offerer. The usage of FEC framework instance is offerer. The usage of the FEC Framework instance is explained in the
explained the FEC Framework document [RFC6363]. FEC Framework document [RFC6363].
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), an alternative parameters is one method (briefly explained above), an alternative
method would be to have a unicast based generic protocol that could method would be to have a unicast-based generic protocol that could
be used by two nodes independent of the application's signaling be used by two nodes, independent of the application's signaling
protocol. The latter is not covered by this document, of course. protocol. The latter is not covered by this document, of course.
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 the 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
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, UDP, or Stream
transport, and uses SDP as the encoding format to describe multmedia Control Transmission Protocol (SCTP) transport and uses SDP as the
session attributes. encoding format to describe multimedia session attributes.
SIP already uses an offer/answer model with SDP, described in SIP already uses an offer/answer model with SDP as described in
[RFC3264], to exchange the information between two nodes to [RFC3264] to exchange information between two nodes to establish
establish unicast sessions between them. This document extends the unicast sessions between them. This document extends the usage of
usage of this model for exchanging the FEC Framework Configuration this model for exchanging the FEC Framework Configuration Information
Information, explained in section 4. Any SDP specific enhancements (described in Section 4). Any SDP-specific enhancements to
to accommodate the FEC Framework are covered in the SDP Elements accommodate the FEC Framework are covered in the SDP elements
specification [RFC6364]. specification [RFC6364].
5.2.2. RTSP 5.2.2. RTSP
Real-Time Streaming Protocol (RTSP) [RFC2326] is an application- RTSP [RFC2326] is an application-level signaling protocol for control
level signaling protocol for control over the delivery of data with over the delivery of data with real-time properties. RTSP provides
real-time properties. RTSP provides an extensible framework to an extensible framework to enable controlled, on-demand delivery of
enable controlled, on-demand delivery of real-time data, such as real-time data such as audio and video. RTSP runs on either TCP or
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 defines 'FEC Protection Needed' new parameters. This specification defines the
option-tag (please see section 7 for IANA Considerations) and 'FEC-protection-needed' option tag (please see Section 7 for IANA
prescribes including it in the Require (or Proxy-Require) header of Considerations) and prescribes including it in the Require (or
SETUP (method) request message, so as to request for FEC protection Proxy-Require) header of SETUP (method) request messages, so as to
for the data. request FEC protection for the data.
The node receiving such request either responds with "200 OK" The node receiving such a request either responds with a '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
Framework Configuration Information for each Instance) or "551 Framework Configuration Information for each instance) or a '551
Option not supported" message. A sample of related message exchange Option not supported' message. A sample of a related message
is shown below - exchange is shown 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-protection-needed Require: FEC-protection-needed
Node2->Node1: RTSP/1.0 200 OK Node2->Node1: RTSP/1.0 200 OK
CSeq: 1 CSeq: 1
Transport: <omitted for simplicity> Transport: <omitted for simplicity>
The requesting node (Node1) may then send a new SETUP message to The requesting node (Node1) may then send a new SETUP message to
convey the selected FEC protection to Node2, and proceed with convey the selected FEC protection to Node2 and proceed with regular
regular RTSP messaging. RTSP messaging.
Suffice to say, if the requesting node (Node1) received '551 Option Suffice it to say that if the requesting node (Node1) received a '551
not supported' response from Node2, then the requesting node (Node1) Option not supported' response from Node2, then the requesting node
may send the SETUP message without using the Require header. (Node1) may send the SETUP message without using the Require header.
6. Security Considerations 6. Security Considerations
This document recommends SAP message(s) be authenticated to ensure This document recommends that SAP message(s) be authenticated to
sender authentication, as described in section 5.1. ensure sender authentication, as described in Section 5.1.
There is no additional security consideration other than what's There are no additional security considerations other than those
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 RTSP Option tag IANA has registered a new RTSP option tag (option-tag), listed below,
(option-tag) listed below in the RTSP/1.0 Option Tags table of the in the RTSP/1.0 Option Tags table of the "Real Time Streaming
"Real Time Streaming Protocol (RTSP)/1.0 Parameters" registry Protocol (RTSP)/1.0 Parameters" registry available from
available from http://www.iana.org/, and provides the following http://www.iana.org/, and it provides the following information in
information in compliance with section 3.8.1 in [RFC2326]: compliance with Section 3.8.1 of [RFC2326]:
. Name of option-tag = FEC-protection-needed o Name of option-tag: FEC-protection-needed
. Description = See section 5.2.2 o Description: See Section 5.2.2
. Change of Control = IETF o Change 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, Ulas Kozat and David Harrington for greatly Ali Begen, Mark Watson, Ulas Kozat, and David Harrington for greatly
improving this document. improving this document.
This document was prepared using 2-Word-v2.0.template.dot. 9. References
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 9.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6363] Watson, M., "Forward Error Correction (FEC) Framework", [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFC6363, March 2011. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6364] Begen, A., "Session Description Protocol Elements for [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
FEC Framework ", RFC6364, October 2011. Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Announcement Protocol", RFC 2974, October 2000. Correction (FEC) Framework", RFC 6363, October 2011.
9.2. Informative References [RFC6364] Begen, A., "Session Description Protocol Elements for the
Forward Error Correction (FEC) Framework", RFC 6364,
October 2011.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 9.2. Informative References
Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
with Session Description Protocol (SDP)", RFC 3264, June Streaming Protocol (RTSP)", RFC 2326, April 1998.
2002.
[RFC2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Streaming Protocol (RTSP)", RFC 2326, April 1998. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3261] Handley, M., Schulzrinne, H., Schooler, E. and J. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Rosenberg, "SIP: Session Initiation Protocol", RFC 3261, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC4601] Fenner, etc., "Protocol Independent Multicast - Sparse [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Mode (PIM-SM): Protocol Specification", RFC 4601, August Description Protocol", RFC 4566, July 2006.
2006.
[RFC3547] Baugher, etc., "The Group Domain of Interpretation", RFC [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
3547, July 2003. "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
Author's Addresses Author's Address
Rajiv Asati Rajiv Asati
Cisco Systems, Cisco Systems
7025-6 Kit Creek Rd, RTP, NC, 27709-4987 7025-6 Kit Creek Rd.
Email: rajiva@cisco.com RTP, NC 27709-4987
EMail: rajiva@cisco.com
 End of changes. 142 change blocks. 
438 lines changed or deleted 419 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/