rfc3208.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,549 行 · 第 1/5 页
TXT
1,549 行
Network Working Group T. Speakman
Request for Comments: 3208 Cisco Systems
Category: Experimental J. Crowcroft
UCL
J. Gemmell
Microsoft
D. Farinacci
Procket Networks
S. Lin
Juniper Networks
D. Leshchiner
TIBCO Software
M. Luby
Digital Fountain
T. Montgomery
Talarian Corporation
L. Rizzo
University of Pisa
A. Tweedly
N. Bhaskar
R. Edmonstone
R. Sumanasekera
L. Vicisano
Cisco Systems
December 2001
PGM Reliable Transport Protocol Specification
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Pragmatic General Multicast (PGM) is a reliable multicast transport
protocol for applications that require ordered or unordered,
duplicate-free, multicast data delivery from multiple sources to
multiple receivers. PGM guarantees that a receiver in the group
either receives all data packets from transmissions and repairs, or
is able to detect unrecoverable data packet loss. PGM is
Speakman, et. al. Experimental [Page 1]
RFC 3208 PGM Reliable Transport Protocol December 2001
specifically intended as a workable solution for multicast
applications with basic reliability requirements. Its central design
goal is simplicity of operation with due regard for scalability and
network efficiency.
Table of Contents
1. Introduction and Overview .................................. 3
2. Architectural Description .................................. 9
3. Terms and Concepts ......................................... 12
4. Procedures - General ....................................... 18
5. Procedures - Sources ....................................... 19
6. Procedures - Receivers ..................................... 22
7. Procedures - Network Elements .............................. 27
8. Packet Formats ............................................. 31
9. Options .................................................... 40
10. Security Considerations .................................... 56
11. Appendix A - Forward Error Correction ...................... 58
12. Appendix B - Support for Congestion Control ................ 72
13. Appendix C - SPM Requests .................................. 79
14. Appendix D - Poll Mechanism ................................ 82
15. Appendix E - Implosion Prevention .......................... 92
16. Appendix F - Transmit Window Example ....................... 98
17 Appendix G - Applicability Statement ....................... 103
18. Abbreviations .............................................. 105
19. Acknowledgments ............................................ 106
20. References ................................................. 106
21. Authors' Addresses.......................................... 108
22. Full Copyright Statement ................................... 111
Nota Bene:
The publication of this specification is intended to freeze the
definition of PGM in the interest of fostering both ongoing and
prospective experimentation with the protocol. The intent of that
experimentation is to provide experience with the implementation and
deployment of a reliable multicast protocol of this class so as to be
able to feed that experience back into the longer-term
standardization process underway in the Reliable Multicast Transport
Working Group of the IETF. Appendix G provides more specific detail
on the scope and status of some of this experimentation. Reports of
experiments include [16-23]. Additional results and new
experimentation are encouraged.
Speakman, et. al. Experimental [Page 2]
RFC 3208 PGM Reliable Transport Protocol December 2001
1. Introduction and Overview
A variety of reliable protocols have been proposed for multicast data
delivery, each with an emphasis on particular types of applications,
network characteristics, or definitions of reliability ([1], [2],
[3], [4]). In this tradition, Pragmatic General Multicast (PGM) is a
reliable transport protocol for applications that require ordered or
unordered, duplicate-free, multicast data delivery from multiple
sources to multiple receivers.
PGM is specifically intended as a workable solution for multicast
applications with basic reliability requirements rather than as a
comprehensive solution for multicast applications with sophisticated
ordering, agreement, and robustness requirements. Its central design
goal is simplicity of operation with due regard for scalability and
network efficiency.
PGM has no notion of group membership. It simply provides reliable
multicast data delivery within a transmit window advanced by a source
according to a purely local strategy. Reliable delivery is provided
within a source's transmit window from the time a receiver joins the
group until it departs. PGM guarantees that a receiver in the group
either receives all data packets from transmissions and repairs, or
is able to detect unrecoverable data packet loss. PGM supports any
number of sources within a multicast group, each fully identified by
a globally unique Transport Session Identifier (TSI), but since these
sources/sessions operate entirely independently of each other, this
specification is phrased in terms of a single source and extends
without modification to multiple sources.
More specifically, PGM is not intended for use with applications that
depend either upon acknowledged delivery to a known group of
recipients, or upon total ordering amongst multiple sources.
Rather, PGM is best suited to those applications in which members may
join and leave at any time, and that are either insensitive to
unrecoverable data packet loss or are prepared to resort to
application recovery in the event. Through its optional extensions,
PGM provides specific mechanisms to support applications as disparate
as stock and news updates, data conferencing, low-delay real-time
video transfer, and bulk data transfer.
In the following text, transport-layer originators of PGM data
packets are referred to as sources, transport-layer consumers of PGM
data packets are referred to as receivers, and network-layer entities
in the intervening network are referred to as network elements.
Speakman, et. al. Experimental [Page 3]
RFC 3208 PGM Reliable Transport Protocol December 2001
Unless otherwise specified, the term "repair" will be used to
indicate both the actual retransmission of a copy of a missing packet
or the transmission of an FEC repair packet.
Terminology
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 RFC 2119 [14] and
indicate requirement levels for compliant PGM implementations.
1.1. Summary of Operation
PGM runs over a datagram multicast protocol such as IP multicast [5].
In the normal course of data transfer, a source multicasts sequenced
data packets (ODATA), and receivers unicast selective negative
acknowledgments (NAKs) for data packets detected to be missing from
the expected sequence. Network elements forward NAKs PGM-hop-by-
PGM-hop to the source, and confirm each hop by multicasting a NAK
confirmation (NCF) in response on the interface on which the NAK was
received. Repairs (RDATA) may be provided either by the source
itself or by a Designated Local Repairer (DLR) in response to a NAK.
Since NAKs provide the sole mechanism for reliability, PGM is
particularly sensitive to their loss. To minimize NAK loss, PGM
defines a network-layer hop-by-hop procedure for reliable NAK
forwarding.
Upon detection of a missing data packet, a receiver repeatedly
unicasts a NAK to the last-hop PGM network element on the
distribution tree from the source. A receiver repeats this NAK until
it receives a NAK confirmation (NCF) multicast to the group from that
PGM network element. That network element responds with an NCF to
the first occurrence of the NAK and any further retransmissions of
that same NAK from any receiver. In turn, the network element
repeatedly forwards the NAK to the upstream PGM network element on
the reverse of the distribution path from the source of the original
data packet until it also receives an NCF from that network element.
Finally, the source itself receives and confirms the NAK by
multicasting an NCF to the group.
While NCFs are multicast to the group, they are not propagated by PGM
network elements since they act as hop-by-hop confirmations.
Speakman, et. al. Experimental [Page 4]
RFC 3208 PGM Reliable Transport Protocol December 2001
To avoid NAK implosion, PGM specifies procedures for subnet-based NAK
suppression amongst receivers and NAK elimination within network
elements. The usual result is the propagation of just one copy of a
given NAK along the reverse of the distribution path from any network
with directly connected receivers to a source.
The net effect is that unicast NAKs return from a receiver to a
source on the reverse of the path on which ODATA was forwarded, that
is, on the reverse of the distribution tree from the source. More
specifically, they return through exactly the same sequence of PGM
network elements through which ODATA was forwarded, but in reverse.
The reasons for handling NAKs this way will become clear in the
discussion of constraining repairs, but first it's necessary to
describe the mechanisms for establishing the requisite source path
state in PGM network elements.
To establish source path state in PGM network elements, the basic
data transfer operation is augmented by Source Path Messages (SPMs)
from a source, periodically interleaved with ODATA. SPMs function
primarily to establish source path state for a given TSI in all PGM
network elements on the distribution tree from the source. PGM
network elements use this information to address returning unicast
NAKs directly to the upstream PGM network element toward the source,
and thereby insure that NAKs return from a receiver to a source on
the reverse of the distribution path for the TSI.
SPMs are sent by a source at a rate that serves to maintain up-to-
date PGM neighbor information. In addition, SPMs complement the role
of DATA packets in provoking further NAKs from receivers, and
maintaining receive window state in the receivers.
As a further efficiency, PGM specifies procedures for the constraint
of repairs by network elements so that they reach only those network
segments containing group members that did not receive the original
transmission. As NAKs traverse the reverse of the ODATA path
(upward), they establish repair state in the network elements which
is used in turn to constrain the (downward) forwarding of the
corresponding RDATA.
Besides procedures for the source to provide repairs, PGM also
specifies options and procedures that permit designated local
repairers (DLRs) to announce their availability and to redirect
repair requests (NAKs) to themselves rather than to the original
source. In addition to these conventional procedures for loss
recovery through selective ARQ, Appendix A specifies Forward Error
Correction (FEC) procedures for sources to provide and receivers to
request general error correcting parity packets rather than selective
retransmissions.
Speakman, et. al. Experimental [Page 5]
RFC 3208 PGM Reliable Transport Protocol December 2001
Finally, since PGM operates without regular return traffic from
receivers, conventional feedback mechanisms for transport flow and
congestion control cannot be applied. Appendix B specifies a TCP-
friendly, NE-based solution for PGM congestion control, and cites a
reference to a TCP-friendly, end-to-end solution for PGM congestion
control.
In its basic operation, PGM relies on a purely rate-limited
transmission strategy in the source to bound the bandwidth consumed
by PGM transport sessions and to define the transmit window
maintained by the source.
PGM defines four basic packet types: three that flow downstream
(SPMs, DATA, NCFs), and one that flows upstream (NAKs).
1.2. Design Goals and Constraints
PGM has been designed to serve that broad range of multicast
applications that have relatively simple reliability requirements,
and to do so in a way that realizes the much advertised but often
unrealized network efficiencies of multicast data transfer. The
usual impediments to realizing these efficiencies are the implosion
of negative and positive acknowledgments from receivers to sources,
repair latency from the source, and the propagation of repairs to
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?