One document matched: draft-ietf-fecframe-config-signaling-00.txt
FECFRAME Working Group Rajiv Asati
Internet Draft Cisco Systems
Intended status: Standards Track July 4, 2008
Expires: January 2009
Signaling Protocol to convey FEC Framework Configuration Information
draft-ietf-fecframe-config-signaling-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
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
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
FEC Framework document [FECARCH] defines the FEC Framework
Configuration Information necessary for the FEC framework operation.
This document describes one signaling protocol to determine and
dynamically communicate the Configuration information between
sender(s) and receiver(s).
Asati Expires January 2, 2009 [Page 1]
Internet-Draft FEC Framework Config Signaling July 2008
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction...................................................2
2. Terminology/Abbreviations......................................3
3. FEC Framework Configuration Information........................4
3.1. Encoding Format...........................................5
4. Signaling Protocol.............................................6
4.1. Signaling Protocol for Multicasting.......................7
4.1.1. Sender Procedure.....................................9
4.1.2. Receiver Procedure..................................10
4.2. Signaling Protocol for Unicasting........................11
4.2.1. SIP.................................................12
4.2.2. RSTP................................................12
4.2.3. DSM-CC..............................................13
5. Security Considerations.......................................13
6. IANA Considerations...........................................13
7. Conclusions...................................................14
8. Acknowledgments...............................................14
9. References....................................................15
9.1. Normative References.....................................15
9.2. Informative References...................................15
Author's Addresses...............................................16
Intellectual Property Statement..................................16
Disclaimer of Validity...........................................16
1. Introduction
FEC Framework document [FECARCH] defines the FEC Framework
Configuration Information that governs the overall FEC framework
operation common to any FEC scheme. This information MUST be
available at both sender and reciever(s). This document describes one
signalling protocol to determine and communicate the Configuration
information between sender and receiver(s). The configuration
Asati Expires January 2, 2009 [Page 2]
Internet-Draft FEC Framework Config Signaling July 2008
information may be encoded in any compatible format such as SDP
[RFC4566], XML etc. The signaling protocol is intended to be generic
and could be utilized by any FEC scheme and/or any Content Delivery
Protocol (CDP).
This document doesn't describe any FEC scheme specifics information
(for example, how are source blocks are constructed) or any sender or
receiver side operation for a particular FEC scheme (for example,
whether the receiver makes use of one or more repair flows that are
received) etc. Such FEC scheme specifics should be covered in
separate document(s). This document doesn't mandate a particular
encoding format for the configuration information either.
<What is CDP>
The FEC Framework document [FECARCH] defines a Content Delivery
Protocol (CDP) as a complete (suite of) specification which, through
the use of FEC Framework, is able to make use of a particular FEC
scheme to provide FEC capabilities. In other words, CDP is specific
to a FEC scheme, but makes use of common building blocks (including
signaling protocol) as defined in the FEC Framework document
[FECARCH].
This document is structured such that Section 2 describes the terms
used in this document, section 3 describes the FEC Framework
configuration information, section 4 describes the signalling
protocol for the multicast, section 5 describes the signalling
protocol for the unicast, and section 6 describes security
consideration.
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.
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
This document makes use of the terms/abbreviations defined in the FEC
Framework document [FECARCH]. Additionally, it defines
Asati Expires January 2, 2009 [Page 3]
Internet-Draft FEC Framework Config Signaling July 2008
o Media Sender - Node performing the Media encoding and producing
the original media flow to the 'FEC Sender'
o Media Receiver - Node performing the Media decoding;
o FEC Sender - Node performing the FEC encoding on the original
stream to produce the FEC stream
o FEC Receiver - Node performing the FEC decoding, as needed, and
providing the original media flow to the Media receiver.
o Sender - Same as FEC Sender
o Receiver - Same as FEC Receiver
o (Media) Stream - A single media instance i.e. an audio stream or
a video stream.
This documents deliberately refers to the 'FEC Sender' and 'FEC
Receiver' as the 'Sender' and 'Receiver' respectively.
3. FEC Framework Configuration Information
The FEC Framework [FECARCH] defines a minimum set of information that
MUST be communicated between the sender and receiver(s) for a proper
operation of an FEC scheme. This information is referred to as "FEC
Framework Configuration Information". This is the information that
the FEC Framework needs in order to apply FEC protection to the
transport flows.
A single instance of the FEC Framework provides FEC protection for
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
Framework document [FECARCH], the FEC Framework Configuation
Information includes, for each instance of the FEC Framework:
1. Identification of Source Flow(s)
2. Identification of the repair flow(s)
3. Identification of FEC Scheme
Asati Expires January 2, 2009 [Page 4]
Internet-Draft FEC Framework Config Signaling July 2008
4. Length of Source FEC payload ID
5. FEC Scheme Specific Information (FSSI)
FSSI basically provides an opaque container to encode FEC scheme
specific configuration information such as buffer size, decoding
wait-time etc. Please refer to the FEC Framework document [FECARCH]
for more details.
The signaling protocol described in this document requires that the
application layer responsible for the FEC Framework instance i.e. FEC
scheme provide the value for each of the configuration information
parameter (listed above) encoded as per the chosen encoding format.
Failure to receive the complete information, the signaling protocol
module must return an error for the OAM purposes and optionally
convey to the application layer. Please refer to the figure 1 of the
FEC Framework document [FECARCH] for further illustration.
This document does not make any assumption that the 'FEC sender and
receiver' functionality and the 'Media Source/Receiver' functionality
are implemented on the single device, though it is likely to be the
case.
3.1. Encoding Format
The FEC Framework configuration information (listed above in section
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
selection of such encoding format or syntax is independent of the
signaling protocol and beyond the scope of this document.
Whatever encoding format is selected for a particular FEC framework
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
protocol message(s) to convey the chosen encoding format for the
configuration information so that the Payload i.e. configuration
information can be correctly parsed as per the semantics of the
chosen encoding format. Please note that the the encoding format is
not a negotiated parameter, but rather a property of a particular FEC
Framework instance i.e. FEC scheme and/or its implementation.
Additionally, the encoding format for each FEC Framework
configuration parameter must be defined in terms of a sequence of
Asati Expires January 2, 2009 [Page 5]
Internet-Draft FEC Framework Config Signaling July 2008
octets that can be embedded within the payload of the signaling
protocol message(s). The length of the encoding format MUST either
be fixed, or derived from examining the encoded octets themselves.
For example, the initial octets may include some kind of length
indication.
Each instance of the FEC Framework muse use a single encoding format
to describe e.g. encode all of the configuration information
associated with that instance. The signaling protocol may not
validate the encoded information, though it may validate the syntax
or length of the encoded information.
The reader may refer to the SDP elements document [FECSDP], which
describes the usage of 'SDP' encoding format as an example encoding
format for FEC framework configuration information.
4. Signaling Protocol
FEC Framework [FECARCH] requires certain FEC Framework Configuration
Information to be available to both sender and receiver(s). This
configuration information is almost always formulated at the sender
(or on behalf of a sender), the receiver(s) somehow must get this
configuration information. While one may envision a static method to
populate the configuration information at both sender and
receiver(s), it would require the knowledge of every receiver in
advance and that is something not always feasible. Hence, there is a
desire to define and describe dynamic method i.e. signaling protocol
to convey the configuration information from sender to one or more
receivers.
It is important to note that there may be either only one receiver
needing the FEC Framework configuration information to FEC protect a
"unicasted multimedia stream" (such as Video On Demand stream), or
one or more receivers needing the FEC Framework configuration
information to FEC protect a "multicasted multimedia stream" (such as
Broadcast TV or IPTV). While the unicasted stream requires the
identification of the receiver (which typically initiates the
communication) at the sender, the multicasted stream doesn't require
the identification of the receiver at the sender.
Such diversity necessitates describing at least two signaling
protocols - one to deliver the configuration information to many
receivers via multicasting (described in section 4.1), and the other
to deliver the configuration information to one and only one receiver
via unicasting (described in section 4.2).
Asati Expires January 2, 2009 [Page 6]
Internet-Draft FEC Framework Config Signaling July 2008
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
Receiver respectively) such that FEC_Sender1 is serving
FEC_Reciver11,12,13 via the multicast signaling protocol, whereas the
FEC_Sender2 is serving only FEC_Reciever2 via the unicast signaling
protocol.
FEC_Sender2---------| |--------FEC_Receiver2
| |
FEC_Sender1-----IP/MPLS network
|-----------FEC_Receiver11
|-----------FEC_Receiver12
|-----------FEC_Receiver13
Figure 1 Topology using Sender and Receiver
The rest of the section continues to use the terms 'Sender' and
'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver'
respectively.
4.1. Signaling Protocol for Multicasting
A one-to-many signaling protocol is desired in order to effectively
deliver the FEC Framework configuration from one sender to many
receivers. The Session Announcement Protocol (SAP) version 2
[RFC2974] is used as the signaling protocol to multicast the
configuration information. The apparent advantage is that the server
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
FEC Framework Configuration Information for each FEC Framework
instance available at the sender, using the SAP message(s). 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
receiver, acting as the SAP listener, listens on a well known UDP
port and at least one well known multicast group IP address. This
enables the receiver to receives the SAP message(s) and obtains the
FEC Framework Configuration Information for each FEC Framework
Instance.
Asati Expires January 2, 2009 [Page 7]
Internet-Draft FEC Framework Config Signaling July 2008
Using the configuration information, the receiver becomes aware of
available FEC protection options, and may subscribe to one or more
multicast trees to receive the FEC streams using out-of-band
multicasting techniques such as PIM [RFC4601]. This, however, is
beyond the specification 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 be
subjected to the 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
from the RFC2974) -
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
While the RFC2974 includes explanation for each field, the most
interesting is the 'Payload' field. This field is required, by this
specification, to carry the the FEC Framework configuration
information. Subsequently, the 'Payload Type' field, which is a MIME
Asati Expires January 2, 2009 [Page 8]
Internet-Draft FEC Framework Config Signaling July 2008
content type specifier, must describe the encoding format used to
encode the Payload. For example, the 'Payload Type' field may be
application/sdp if the FEC framework configuration information was
encoded in SDP format and placed as SAP payload. Similarly, it would
be application/xml if the FEC framework configuration information was
encoded in XML format.
4.1.1. Sender Procedure
The sender signals the FEC framework configuration for each FEC
framework instance in a periodic SAP announcement message. The SAP
announcement message is sent to a well known multicast IP address and
port. The announcement is multicasted with the same scope as the
session it is announcing.
The SAP module at the sender obtains the FEC Framework configuration
information per Instance from the 'FEC Framework' module and places
that in the SAP payload accordingly. A single SAP (announcement)
message may carry the FEC Framework Configuration Information for
each FEC Framework Instance. This is a preferred method, though the
other method may be to aggregate more than one SAP (announcement)
messages in a single UDP datagram as long as the resulting UDP
datagram length is less than the IP MTU of the outgoing interface.
The IP packet carrying the SAP message must be sent with destination
IP address of either 239.16.33.254 (if IPv4 administrative scope 239.
is selected) or 224.2.127.254 (if IPv4 global scope 224.0.1.0-
238.255.255.255 is selected) or FF0X:0:0:0:0:0:2:7FFE (if IPv6 is
selected, where X is the 4-bit scope value) with UDP destination port
9875. The default IP TTL value should be 255, though the
implementation should allow to set it to any other value. The IP 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
address that is reachable by the receiver. The sender may assign the
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.
Furthermore, the FEC Framework Configuration Information must NOT
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
address as the 'originating source' address to identify the FEC
streams (i.e. source or repair flows). Please refer to IANA
assignments for multicast addresses.
Asati Expires January 2, 2009 [Page 9]
Internet-Draft FEC Framework Config Signaling July 2008
The sender must periodically send the 'SAP announcement' message.
This is required so that the receiver doesn't purge the cached
entry(s) from the database and doesn't trigger the deletion of FEC
Framework configuration information. While the time interval between
repetitions of an announcement can be calculated as per the very
sophisticated but complex formula explained in RFC2974, the preferred
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 time interval must be chosen to ensure that SAP announcement
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
that the default time-out period for the multicast routing entry is
210 seconds, per the PIM specification [RFC4601], but it depends on
the implementation. The implementation of signaling protocol should
provide the flexibility to the operator to choose the complex method
over the simpler method of determining the SAP announcement time
interval. Additionally, the 'time interval' should be signaled within
the FEC Framework configuration Information.
The sender may choose to delete the announced FEC framework
configuration information by sending a 'SAP deletion' message. This
may be used if the sender no longer desires to send any FEC streams.
If the sender needs to modify the announced FEC Framework
configuration Information for one or more FEC instances, then the
sender must send a new announcement message with a different 'Message
Identifier Hash' value as per the rules described in section 5 of
RFC2974. Such announcement message should be sent immediately
(without having to wait for the time-interval) to ensure that the
modifications are received by the receiver as soon as possible. The
sender must send the SAP deletion message to delete the previous SAP
announcement message (i.e. with the previous 'Message Identifier
Hash' value).
4.1.2. Receiver Procedure
The receiver must listen on UDP port 9875 for packets arriving with
IP destination address of either 239.16.33.254 (if IPv4
administrative scope is selected) or 224.2.127.254 (if IPv4 global
scope is selected) or FF0X:0:0:0:0:0:2:7FFE (if IPv6 is selected,
where X is the 4-bit scope value).
The receiver, upon receiving a SAP announcement message, creates an
entry, if it doesn't already exists, in a local database and passes
the FEC Framework configuration information from the SAP Payload
field to the 'FEC Framework' module. When the same annoucement
Asati Expires January 2, 2009 [Page 10]
Internet-Draft FEC Framework Config Signaling July 2008
(please see section 5 of RFC2974) is received the next time, the
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,
whichever is greater.
Editor's Note: SAP doesn't allow the time-interval to be signaled in
the SAP header. Hence, we need this to be specified in the FEC
Framework Configuration Information (allowed by SAP). For example,
the usage of "r=" (repeat time) field in SDP.
The receiver, upon receiving a SAP delete message, must delete the
matching SAP entry in its database. This should result in the
receiver no longer using the relevant FEC framework configuration
information for every instance, and should no longer subscribe to any
related FEC streams.
4.2. Signaling Protocol for Unicasting
The signaling protocol for unicasting enables two nodes, which wish
to communicate one-to-one across an IP network, to exchange the FEC
Framework configuration Information. This exchange may be
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
unicasting for a particular content to the multimedia (VoD) server,
which may offer various options such as encodings, bitrates,
transport etc. for the content. The client selects the suitable
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
offer/answer signaling, described in [RFC3264], is commonly utilized
by many application protocols such as SIP, RTSP etc.
The fact that two nodes desiring unicast communication almost always
rely on an application to first exchange the application related
parameters via the signaling protocol, it is logical to enhance such
signaling protocol(s) to (a) convey the desire for the FEC protection
and (b) subsequently also exchange FEC parameters i.e. FEC Framework
Configuration information. This enables the node acting as the
offerer to offer 'FEC Framework Configuration Information' for each
of available FEC instances, and the node acting as the answerer
conveying the chosen FEC Framework instance(s) to the offerer. The
usage of FEC framework instance i.e. FEC scheme is beyond the scope
Asati Expires January 2, 2009 [Page 11]
Internet-Draft FEC Framework Config Signaling July 2008
of this document. Please refer to the FEC Framework document
[FECARCH].
While enhancing the application's signaling protocol to exchange FEC
parameters is one method (briefly explained above), another method
would be to have a unicast based generic protocol that could be used
by two nodes independent of the application's signaling protocol. The
latter method is under investigation and may be covered in future.
4.2.1. SIP
SIP [RFC3261] is an application-level signaling protocol to create,
modify, and terminate multimedia sessions with one or more
participants. SIP also enables the participants to discover one
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
transport, and uses SDP to describe multmedia session attributes.
SIP already uses offer/answer model with SDP, described in [RFC3264],
to exchange the information between two nodes to establish unicast
sessions between them. This specification extends the usage of this
model for exchanging the FEC Framework Configuration Information,
explained in section 3, between two SIP speaking nodes.
4.2.2. RSTP
RTSP [RFC2326] is an application-level signaling protocol for control
over the delivery of data with real-time properties. RTSP provides an
extensible framework to enable controlled, on-demand delivery of
real-time data, such as audio and video. RTSP runs on either TCP or
UDP transports.
RTSP already provides an ability to extend the existing method with
new parameters. This specification suggests requesting for the FEC
protection options by including "FEC Protection Required" in the
"Require:" header of SETUP (method) request message. The node
receiving such request either responds with "200 OK" message that
includes offers i.e. available FEC options (e.g. FEC Framework
Configuration Information for each Instnace) or "551 Option not
supported" message. A sample of related message exchange is shown
below -
Asati Expires January 2, 2009 [Page 12]
Internet-Draft FEC Framework Config Signaling July 2008
Node1->Node2: SETUP < . . .> RTSP/1.0
Cseq: 1
Transport: <omitted for simplicity>
Require: FEC Protections Required
Node2->Node1: RTSP/1.0 200 OK
Cseq: 1
Transport: <omitted for simplicity>
OR
Node2->Node1: RTSP/1.0 551 Option Not supported
Cseq: 1
Transport: <omitted for simplicity>
The requesting node (Node1) may then send either the SETUP message
without using the Require: header, if the remote node didn't support
the "FEC protection", or a new SETUP message to request the selected
FEC protection streams.
4.2.3. DSM-CC
DSM-CC is a predominant suite of protocols including the signaling
protocol used for the video control plane in Cable/MSO networks that
have offered video services for decades. Unfortunately, DSM-CC is
actually standardised in MPEG-2 ISO/IEC 13818-6 (part 6 of the MPEG-2
standard), not within the IETF yet, hence, DSM-CC related
enhancements aren't covered in this document. The same is applicable
to Session Setup protocol (SSP) and Lightweight Stream Control
Protocol (LSCP) that are derived from DSM-CC, as well.
5. Security Considerations
There are no additional security consideration other than what's
already covered in RFC2974 for SAP, RFC2326 for RTSP, RFC3261 for SIP
etc.
6. IANA Considerations
None.
Asati Expires January 2, 2009 [Page 13]
Internet-Draft FEC Framework Config Signaling July 2008
7. Conclusions
TBD.
8. Acknowledgments
Thanks to Colin Perkins for pointing out the issue with the time-
interval for the SAP messages. Additionally, many thanks to Mark
Watson, Ali Begen and Ulas Kozat for helping with this proposal.
This document was prepared using 2-Word-v2.0.template.dot.
Asati Expires January 2, 2009 [Page 14]
Internet-Draft FEC Framework Config Signaling July 2008
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[FECARCH] Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-01 (work in progress),,
November 2007.
[FECSDP] Begen, A., "SDP Elements for FEC Framework", draft-begen-
fecframe-sdp-elements-00 (work in progress), November 11
2007.
9.2. Informative References
[RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3261] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4601] Fenner, etc., "Protocol Independent Multicast - Sparse Mode
(PIM-SM) : Protocol Specification", RFC 4601, August 2006.
[RFC3547] Baugher, etc., "The Group Domain of Interpretation", RFC
3547, July 2003.
Asati Expires January 2, 2009 [Page 15]
Internet-Draft FEC Framework Config Signaling July 2008
Author's Addresses
Rajiv Asati
Cisco Systems,
7025-6 Kit Creek Rd, RTP, NC, 27709-4987
Email: rajiva@cisco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
Asati Expires January 2, 2009 [Page 16]
Internet-Draft FEC Framework Config Signaling July 2008
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Asati Expires January 2, 2009 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 02:01:37 |