When to use RFC 6553, 6554 and IPv6-in-IPv6
draft-ietf-roll-useofrplinfo-13
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9008.
|
|
|---|---|---|---|
| Authors | Ines Robles , Michael Richardson , Pascal Thubert | ||
| Last updated | 2017-04-03 | ||
| Replaces | draft-robles-roll-useofrplinfo | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
IOTDIR Telechat review
(of
-40)
by Mališa Vučinić
Ready w/issues
GENART Last Call review
(of
-25)
by Russ Housley
Ready w/nits
TSVART Last Call review
(of
-25)
by Colin Perkins
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Associated WG milestone |
|
||
| Document shepherd | Ralph Droms | ||
| IESG | IESG state | Became RFC 9008 (Proposed Standard) | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | "Ralph Droms" <rdroms@cisco.com> |
draft-ietf-roll-useofrplinfo-13
Network Working Group B. Burman
Internet-Draft A. Akram
Updates: 5104 (if approved) Ericsson
Intended status: Standards Track R. Even
Expires: January 25, 2015 Huawei Technologies
M. Westerlund
Ericsson
July 24, 2014
RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-02
Abstract
With the increased popularity of real-time multimedia applications,
it is desirable to provide good control of resource usage, and users
also demand more control over communication sessions. This document
describes how a receiver in a multimedia conversation can pause and
resume incoming data from a sender by sending real-time feedback
messages when using Real-time Transport Protocol (RTP) for real time
data transport. This document extends the Codec Control Messages
(CCM) RTCP feedback package by explicitly allowing and describing
specific use of existing CCM messages and adding a group of new real-
time feedback messages used to pause and resume RTP data streams.
This document updates RFC 5104.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 25, 2015.
Burman, et al. Expires January 25, 2015 [Page 1]
Internet-Draft RTP Stream Pause July 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7
3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8
3.3. RTP Mixer to Media Sender in Point-to-Multipoint . . . . 9
3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 9
3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 10
4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 10
4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11
4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 11
4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
4.6. Retransmitting Requests . . . . . . . . . . . . . . . . . 12
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 12
4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 12
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 13
5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 14
5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 15
5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 16
5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 17
6. Participant States . . . . . . . . . . . . . . . . . . . . . 18
6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 19
6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 20
Burman, et al. Expires January 25, 2015 [Page 2]
Internet-Draft RTP Stream Pause July 2014
6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 20
6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 20
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 20
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.4. REFUSE . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 26
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 29
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 30
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 31
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 33
10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 36
10.4. Point-to-Multipoint using Translator . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
12. Security Considerations . . . . . . . . . . . . . . . . . . . 42
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
15.1. Normative References . . . . . . . . . . . . . . . . . . 42
15.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 44
A.1. Modifications Between Version -01 and -02 . . . . . . . . 44
A.2. Modifications Between Version -00 and -01 . . . . . . . . 44
Authors"). In all cases hop by hop can be used.
In cases where no IP-in-IP header is needed, the column is left
blank.
In all cases the RPI headers are needed, since it identifies
inconsistencies (loops) in the routing topology. In all cases the
RH3 is not need because we do not indicate the route in stroing mode.
The leaf can be a router 6LR or a host, both indicated as 6LN
(Figure 2).
Robles, et al. Expires October 5, 2017 [Page 9]
Internet-Draft Useof6553 April 2017
+--------------+-----------+---------------+
| Use Case | IP-in-IP | IP-in-IP dst |
+--------------+-----------+---------------+
| Raf to root | No | -- |
| root to Raf | No | -- |
| root to ~Raf | No | -- |
| ~Raf to root | Yes | root |
| Raf to Int | No | -- |
| Int to Raf | Yes | raf |
| ~Raf to Int | root | raf |
| ~Raf to Int | Yes | root |
| Int to ~Raf | Yes | hop |
| Raf to Raf | No | -- |
| Raf to ~Raf | No | -- |
| ~Raf to Raf | Yes | dst |
| ~Raf to ~Raf | Yes | hop |
+--------------+-----------+---------------+
Table 1: IP-in-IP encapsulation in Storing mode
5.1. Example of Flow from RPL-aware-leaf to root
In storing mode, RFC 6553 (RPI) is used to send RPL Information
instanceID and rank information.
As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does
not generally issue DIO messages; a leaf node accepts DIO messages
from upstream. (When the inconsistency in routing occurs, a leaf
node will generate a DIO with an infinite rank, to fix it). It may
issue DAO and DIS messages though it generally ignores DAO and DIS
messages.
In this case the flow comprises:
RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR)
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from source (6LN) to destination (6LBR).
As it was mentioned In this document 6LRs, 6LBR are always full-
fledge RPL routers.
The 6LN inserts the RPI header, and sends the packet to 6LR which
decrements the rank in RPI and sends the packet up. When the packet
arrives at 6LBR, the RPI is removed and the packet is processed.
No IP-in-IP header is required.
Robles, et al. Expires October 5, 2017 [Page 10]
Internet-Draft Useof6553 April 2017
The RPI header can be removed by the 6LBR because the packet is
addressed to the 6LBR. The 6LN must know that it is communicating
with the 6LBR to make use of this scenario. The 6LN can know the
address of the 6LBR because it knows the address of the root via the
DODAGID in the DIO messages.
+-------------------+-----+-------+------+
| Header | 6LN | 6LR_i | 6LBR |
+-------------------+-----+-------+------+
| Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | RPI |
| Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | -- |
+-------------------+-----+-------+------+
Storing: Summary of the use of headers from RPL-aware-leaf to root
5.2. Example of Flow from root to RPL-aware-leaf
In this case the flow comprises:
root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from source (6LBR) to destination (6LN).
In this case the 6LBR inserts RPI header and sends the packet down,
the 6LR is going to increment the rank in RPI (examines instanceID
for multiple tables), the packet is processed in 6LN and RPI removed.
No IP-in-IP header is required.
+-------------------+------+-------+------+
| Header | 6LBR | 6LR_i | 6LN |
+-------------------+------+-------+------+
| Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | RPI |
| Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | -- |
+-------------------+------+-------+------+
Storing: Summary of the use of headers from root to RPL-aware-leaf
Robles, et al. Expires October 5, 2017 [Page 11]
Internet-Draft Useof6553 April 2017
5.3. Example of Flow from root to not-RPL-aware-leaf
In this case the flow comprises:
root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from source (6LBR) to destination (IPv6).
As the RPI extension can be ignored by the not-RPL-aware leaf, this
situation is identical to the previous scenario.
+-------------------+------+-------+----------------+
| Header | 6LBR | 6LR_i | IPv6 |
+-------------------+------+-------+----------------+
| Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | -- |
| Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | RPI (Ignored) |
+-------------------+------+-------+----------------+
Storing: Summary of the use of headers from root to not-RPL-aware-
leaf
5.4. Example of Flow from not-RPL-aware-leaf to root
In this case the flow comprises:
not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR)
6LR_i are the intermediate routers from source to destination. In
this case, "1 < i >= n", n is the number of routers (6LR) that the
packet go through from source (IPv6) to destination (6LBR). For
example, 6LR_1 (i=1) is the router that receives the packets from the
IPv6 node.
When the packet arrives from IPv6 node to 6LR_1, the 6LR_1 will
insert a RPI header, encapsuladed in a IPv6-in-IPv6 header. The
IPv6-in-IPv6 header can be addressed to the next hop, or to the root.
The root removes the header and processes the packet.
Robles, et al. Expires October 5, 2017 [Page 12]
Internet-Draft Useof6553 April 2017
+------------+------+---------------+---------------+---------------+
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |
+------------+------+---------------+---------------+---------------+
| Inserted | -- | IP-in-IP(RPI) | -- | -- |
| headers | | | | |
| Removed | -- | -- | -- | IP-in-IP(RPI) |
| headers | | | | |
| Re-added | -- | -- | -- | -- |
| headers | | | | |
| Modified | -- | -- | IP-in-IP(RPI) | -- |
| headers | | | | |
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+------------+------+---------------+---------------+---------------+
Storing: Summary of the use of headers from not-RPL-aware-leaf to
root
5.5. Example of Flow from RPL-aware-leaf to Internet
RPL information from RFC 6553 MAY go out to Internet as it will be
ignored by nodes which have not been configured to be RPI aware.
In this case the flow comprises:
RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from source (6LN) to 6LBR.
No IP-in-IP header is required.
Note: In this use case we use a node as leaf, but this use case can
be also applicable to any RPL-node type (e.g. 6LR)
+-------------------+------+-------+------+----------------+
| Header | 6LN | 6LR_i | 6LBR | Internet |
+-------------------+------+-------+------+----------------+
| Inserted headers | RPI | -- | -- | -- |
| Removed headers | -- | -- | -- | -- |
| Re-added headers | -- | -- | -- | -- |
| Modified headers | -- | RPI | -- | -- |
| Untouched headers | -- | -- | RPI | RPI (Ignored) |
+-------------------+------+-------+------+----------------+
Storing: Summary of the use of headers from RPL-aware-leaf to
Internet
Robles, et al. Expires October 5, 2017 [Page 13]
Internet-Draft Useof6553 April 2017
5.6. Example of Flow from Internet to RPL-aware-leaf
In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from 6LBR to destination(6LN).
When the packet arrives from Internet to 6LBR the RPI header is added
in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the
rank in the RPI. When the packet arrives at 6LN the RPI header is
removed and the packet processed.
+----------+---------+--------------+---------------+---------------+
| Header | Interne | 6LBR | 6LR_i | 6LN |
| | t | | | |
+----------+---------+--------------+---------------+---------------+
| Inserted | -- | IP-in- | -- | -- |
| headers | | IP(RPI) | | |
| Removed | -- | -- | -- | IP-in-IP(RPI) |
| headers | | | | |
| Re-added | -- | -- | -- | -- |
| headers | | | | |
| Modified | -- | -- | IP-in-IP(RPI) | -- |
| headers | | | | |
| Untouche | -- | -- | -- | -- |
| d | | | | |
| headers | | | | |
+----------+---------+--------------+---------------+---------------+
Storing: Summary of the use of headers from Internet to RPL-aware-
leaf
5.7. Example of Flow from not-RPL-aware-leaf to Internet
In this case the flow comprises:
not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) -->
Internet
6LR_i are the intermediate routers from source to destination. In
this case, "1 < i >= n", n is the number of routers (6LR) that the
packet go through from source(IPv6) to 6LBR.
Robles, et al. Expires October 5, 2017 [Page 14]#x27; Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction
As real-time communication attracts more people, more applications
are created; multimedia conversation applications being one example.
Multimedia conversation further exists in many forms, for example,
peer-to-peer chat application and multiparty video conferencing
controlled by central media nodes, such as RTP Mixers.
Multimedia conferencing may involve many participants; each has its
own preferences for the communication session, not only at the start
but also during the session. This document describes several
scenarios in multimedia communication where a conferencing node or
participant chooses to temporarily pause an incoming RTP [RFC3550]
stream and later resume it when needed. The receiver does not need
to terminate or inactivate the RTP session and start all over again
by negotiating the session parameters, for example using SIP
[RFC3261] with SDP Offer/Answer [RFC3264].
Burman, et al. Expires January 25, 2015 [Page 3]
Internet-Draft RTP Stream Pause July 2014
Centralized nodes, like RTP Mixers or MCUs, which either uses logic
based on voice activity, other measurements, or user input could
reduce the resources consumed in both the sender and the network by
temporarily pausing the RTP streams that aren't required by the RTP
Mixer. If the number of conference participants are greater than
what the conference logic has chosen to present simultaneously to
receiving participants, some participant RTP streams sent to the RTP
Mixer may not need to be forwarded to any other participant. Those
RTP streams could then be temporarily paused. This becomes
especially useful when the media sources are provided in multiple
encoding versions (Simulcast) [I-D.westerlund-avtcore-rtp-simulcast]
or with Multi-Session Transmission (MST) of scalable encoding such as
SVC [RFC6190]. There may be some of the defined encodings or
combination of scalable layers that are not used all of the time.
As the RTP streams required at any given point in time is highly
dynamic in such scenarios, using the out-of-band signaling channel
for pausing, and even more importantly resuming, an RTP stream is
difficult due to the performance requirements. Instead, the pause
and resume signaling should be in the media plane and go directly
between the affected nodes. When using RTP [RFC3550] for media
transport, using Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] appears
appropriate. No currently existing RTCP feedback message explicitly
supports pausing and resuming an incoming RTP stream. As this
affects the generation of packets and may even allow the encoding
process to be paused, the functionality appears to match Codec
Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
[RFC5104] and it is proposed to define the solution as a Codec
Control Message (CCM) extension.
The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is
used by video conferencing systems for flow control. It is desirable
to be able to use that method with a bitrate value of zero for pause
and resume, whenever possible.
2. Definitions
2.1. Abbreviations
3GPP: 3rd Generation Partnership Project
AVPF: Audio-Visual Profile with Feedback (RFC 4585)
BGW: Border Gateway
CCM: Codec Control Messages (RFC 5104)
Burman, et al. Expires January 25, 2015 [Page 4]
Internet-Draft RTP Stream Pause July 2014
CNAME: Canonical Name (RTCP SDES)
CSRC: Contributing Source (RTP)
FB: Feedback (AVPF)
FCI: Feedback Control Information (AVPF)
FIR: Full Intra Refresh (CCM)
FMT: Feedback Message Type (AVPF)
LTE: Long-Term Evolution (3GPP)
MCU: Multipoint Control Unit
MTU: Maximum Transfer Unit
PT: Payload Type (RTP)
RTP: Real-time Transport Protocol (RFC 3550)
RTCP: RTP Control Protocol (RFC 3550)
RTCP RR: RTCP Receiver Report
SDP: Session Description Protocol (RFC 4566)
SGW: Signaling Gateway
SIP: Session Initiation Protocol (RFC 3261)
SSRC: Synchronization Source (RTP)
SVC: Scalable Video Coding
TCP: Transmission Control Protocol (RFC 793)
TMMBR: Temporary Maximum Media Bitrate Request (CCM)
TMMBN: Temporary Maximum Media Bitrate Notification (CCM)
UA: User Agent (SIP)
UDP: User Datagram Protocol (RFC 768)
Burman, et al. Expires January 25, 2015 [Page 5]
Internet-Draft RTP Stream Pause July 2014
2.2. Terminology
In addition to the following, the definitions from RTP [RFC3550],
AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy
[I-D.ietf-avtext-rtp-grouping-taxonomy] also apply in this document.
Feedback Messages: CCM [RFC5104] categorized different RTCP feedback
messages into four types, Request, Command, Indication and
Notification. This document places the PAUSE and RESUME messages
into Request category, PAUSED as Indication and REFUSE as
Notification.
PAUSE Request from an RTP stream receiver to pause a stream
RESUME Request from an RTP stream receiver to resume a paused
stream
PAUSED Indication from an RTP stream sender that a stream is
paused
REFUSE Notification from an RTP stream sender that a PAUSE or
RESUME request will not be honored
Mixer: The intermediate RTP node which receives an RTP stream from
different end points, combines them to make one RTP stream and
forwards to destinations, in the sense described in Topo-Mixer of
RTP Topologies [I-D.ietf-avtcore-rtp-topologies-update].
Participant: A member which is part of an RTP session, acting as
receiver, sender or both.
Paused sender: An RTP stream sender that has stopped its
transmission, i.e. no other participant receives its RTP
transmission, either based on having received a PAUSE request,
defined in this specification, or based on a local decision.
Pausing receiver: An RTP stream receiver which sends a PAUSE
request, defined in this specification, to other participant(s).
Stream: Used as a short term for RTP stream, unless otherwise noted.
Stream receiver: Short for RTP stream receiver; the RTP entity
responsible for receiving an RTP stream, usually a Media
Depacketizer.
Stream sender: Short for RTP stream sender; the RTP entity
responsible for creating an RTP stream, usually a Media
Packetizer.
Burman, et al. Expires January 25, 2015 [Page 6]
Internet-Draft RTP Stream Pause July 2014
2.3. Requirements Language
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 [RFC2119].
3. Use Cases
This section discusses the main use cases for RTP stream pause and
resume.
3.1. Point to Point
This is the most basic use case with an RTP session containing two
End Points. Each End Point sends one or more streams.
+---+ +---+
| A |<------->| B |
+---+ +---+
Figure 1: Point to Point
The usage of RTP stream pause in this use case is to temporarily halt
delivery of streams that the sender provides but the receiver does
not currently use. This can for example be due to minimized
applications where the video stream is not actually shown on any
display, and neither is it used in any other way, such as being
recorded.
In this case, since there is only a single receiver of the stream,
pausing or resuming a stream does not impact anyone else than the
sender and the single receiver of that stream.
RTCWEB WG's use case and requirements document
[I-D.ietf-rtcweb-use-cases-and-requirements] defines the following
API requirements in Appendix A, used also by W3C WebRTC WG:
A8 The Web API must provide means for the web application to mute/
unmute a stream or stream component(s). When a stream is sent to
a peer mute status must be preserved in the stream received by the
peer.
A9 The Web API must provide means for the web application to cease
the sending of a stream to a peer.
This memo provides means to optimize transport usage by stop sending
muted streams and start sending again when unmuting.
Burman, et al. Expires January 25, 2015 [Page 7]
Internet-Draft RTP Stream Pause July 2014
3.2. RTP Mixer to Media Sender
One of the most commonly used topologies in centralized conferencing
is based on the RTP Mixer [I-D.ietf-avtcore-rtp-topologies-update].
The main reason for this is that it provides a very consistent view
of the RTP session towards each participant. That is accomplished
through the Mixer originating its' own streams, identified by SSRC,
and any RTP streams sent to the participants will be sent using those
SSRCs. If the Mixer wants to identify the underlying media sources
for its' conceptual streams, it can identify them using CSRC. The
stream the Mixer provides can be an actual mix of multiple media
sources, but it might also be switching received streams as described
in Sections 3.6-3.8 of [I-D.ietf-avtcore-rtp-topologies-update].
+---+ +-----------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +-----------+ +---+
Figure 2: RTP Mixer in Unicast-only
Which streams that are delivered to a given receiver, A, can depend
on several things. It can either be the RTP Mixer's own logic and
measurements such as voice activity on the incoming audio streams.
It can be that the number of sent media sources exceed what is
reasonable to present simultaneously at any given receiver. It can
also be a human controlling the conference that determines how the
media should be mixed; this would be more common in lecture or
similar applications where regular listeners may be prevented from
breaking into the session unless approved by the moderator. The
streams may also be part of a Simulcast
[I-D.westerlund-avtcore-rtp-simulcast] or scalable encoded (for
Multi-Stream Transmission) [RFC6190], thus providing multiple
versions that can be delivered by the RTP stream sender. These
examples indicate that there are numerous reasons why a particular
stream would not currently be in use, but must be available for use
at very short notice if any dynamic event occurs that causes a
different stream selection to be done in the Mixer.
Because of this, it would be highly beneficial if the Mixer could
request to pause a particular stream from being delivered to it. It
also needs to be able to resume delivery with minimal delay.
Just as for point-to-point (Section 3.1), there is only a single
receiver of the stream, the RTP Mixer, and pausing or resuming a
Burman, et al. Expires January 25, 2015 [Page 8]
Internet-Draft RTP Stream Pause July 2014
Internet-Draft Useof6553 April 2017
The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed
either to the root, or hop-by-hop such that the root can remove the
RPI header before passing upwards.
The originating node will ideally leave the IPv6 flow label as zero
so that the packet can be better compressed through the LLN. The
6LBR will set the flow label of the packet to a non-zero value when
sending to the Internet.
+---------+-----+-------------+-------------+-------------+---------+
| Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne |
| | 6 | | [i=2,..,n]_ | | t |
+---------+-----+-------------+-------------+-------------+---------+
| Inserte | -- | IP-in- | -- | -- | -- |
| d | | IP(RPI) | | | |
| headers | | | | | |
| Removed | -- | -- | -- | IP-in- | -- |
| headers | | | | IP(RPI) | |
| Re- | -- | -- | -- | -- | -- |
| added | | | | | |
| headers | | | | | |
| Modifie | -- | -- | IP-in- | -- | -- |
| d | | | IP(RPI) | | |
| headers | | | | | |
| Untouch | -- | -- | -- | -- | -- |
| ed | | | | | |
| headers | | | | | |
+---------+-----+-------------+-------------+-------------+---------+
Storing: Summary of the use of headers from not-RPL-aware-leaf to
Internet
5.8. Example of Flow from Internet to non-RPL-aware-leaf
In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
6LR_i are the intermediate routers from source to destination. In
this case, "1 < i >= n", n is the number of routers (6LR) that the
packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 6LR_i
updates the rank in the RPI.
The 6LBR will have to add an RPI header within an IP-in-IP header.
The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the
RPI inside.
Robles, et al. Expires October 5, 2017 [Page 15]
Internet-Draft Useof6553 April 2017
The 6LBR MAY set the flow label on the inner IP-in-IP header to zero
in order to aid in compression.
+-----------+----------+---------------+---------------+------------+
| Header | Internet | 6LBR | 6LR_i | IPv6 |
+-----------+----------+---------------+---------------+------------+
| Inserted | -- | IP-in-IP(RPI) | -- | -- |
| headers | | | | |
| Removed | -- | -- | -- | -- |
| headers | | | | |
| Re-added | -- | -- | -- | -- |
| headers | | | | |
| Modified | -- | -- | IP-in-IP(RPI) | -- |
| headers | | | | |
| Untouched | -- | -- | -- | RPI |
| headers | | | | (Ignored) |
+-----------+----------+---------------+---------------+------------+
Storing: Summary of the use of headers from Internet to non-RPL-
aware-leaf
5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf
In [RFC6550] RPL allows a simple one-hop optimization for both
storing and non-storing networks. A node may send a packet destined
to a one-hop neighbor directly to that node. Section 9 in [RFC6550].
In this case the flow comprises:
6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN
6LR_ia are the intermediate routers from source to the common parent
(6LR_x) In this case, "1 <= ia >= n", n is the number of routers
(6LR) that the packet go through from 6LN to the common parent
(6LR_x).
6LR_id are the intermediate routers from the common parent (6LR_x) to
destination 6LN. In this case, "1 <= id >= m", m is the number of
routers (6LR) that the packet go through from the common parent
(6LR_x) to destination 6LN.
This case is assumed in the same RPL Domain. In the common parent,
the direction of RPI is changed (from increasing to decreasing the
rank).
While the 6LR nodes will update the RPI, no node needs to add or
remove the RPI, so no IP-in-IP headers are necessary. This may be
Robles, et al. Expires October 5, 2017 [Page 16]
Internet-Draft Useof6553 April 2017
done regardless of where the destination is, as the included RPI will
be ignored by the receiver.
+---------------+--------+--------+---------------+--------+--------+
| Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN |
| | src | | parent) | | dst |
+---------------+--------+--------+---------------+--------+--------+
| Inserted | RPI | -- | -- | -- | -- |
| headers | | | | | |
| Removed | -- | -- | -- | -- | RPI |
| headers | | | | | |
| Re-added | -- | -- | -- | -- | -- |
| headers | | | | | |
| Modified | -- | RPI | RPI | RPI | -- |
| headers | | | | | |
| Untouched | -- | -- | -- | -- | -- |
| headers | | | | | |
+---------------+--------+--------+---------------+--------+--------+
Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
aware-leaf
5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf
In this case the flow comprises:
6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware
6LN (IPv6)
6LR_ia are the intermediate routers from source (6LN) to the common
parent (6LR_x) In this case, "1 <= ia >= n", n is the number of
routers (6LR) that the packet go through from 6LN to the common
parent (6LR_x).
6LR_id are the intermediate routers from the common parent (6LR_x) to
destination not-RPL-aware 6LN (IPv6). In this case, "1 <= id >= m",
m is the number of routers (6LR) that the packet go through from the
common parent (6LR_x) to destination 6LN.
This situation is identical to the previous situation Section 5.9
Robles, et al. Expires October 5, 2017 [Page 17]
Internet-Draft Useof6553 April 2017
stream does not affect anyone else than the sender and single
receiver of that stream.
3.3. RTP Mixer to Media Sender in Point-to-Multipoint
This use case is similar to the previous section, however the RTP
Mixer is involved in three domains that need to be separated; the
Multicast Network (including participants A and C), participant B,
and participant D. The difference from above is that A and C share a
multicast domain, which is depicted below.
+-----+
+---+ / \ +-----------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+
+ Cast +->| Mixer |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +-----------+ +---+
+-----+
Figure 3: RTP Mixer in Point-to-Multipoint
If the RTP Mixer pauses a stream from A, it will not only pause the
stream towards itself, but will also stop the stream from arriving to
C, which C is heavily impacted by, might not approve of, and should
thus have a say on.
If the Mixer resumes a paused stream from A, it will be resumed also
towards C. In this case, if C is not interested it can simply ignore
the stream and is not impacted as much as above.
In this use case there are several receivers of a stream and special
care must be taken as not to pause a stream that is still wanted by
some receivers.
3.4. Media Receiver to RTP Mixer
An End Point in Figure 2 could potentially request to pause the
delivery of a given stream. Possible reasons include the ones in the
point to point case (Section 3.1) above.
When the RTP Mixer is only connected to individual unicast paths, the
use case and any considerations are identical to the point to point
use case.
However, when the End Point requesting stream pause is connected to
the RTP Mixer through a multicast network, such as A or C in
Burman, et al. Expires January 25, 2015 [Page 9]
Internet-Draft RTP Stream Pause July 2014
Figure 3, the use case instead becomes identical to the one in
Section 3.3, only with reverse direction of the streams and pause/
resume requests.
3.5. Media Receiver to Media Sender Across RTP Mixer
An End Point, like A in Figure 2, could potentially request to pause
the delivery of a given stream, like one of B's, over any of the
SSRCs used by the Mixer by sending a pause request for the CSRC
identifying the stream. However, the authors are of the opinion that
this is not a suitable solution, for several reasons:
1. The Mixer might not include CSRC in it's stream indications.
2. An End Point cannot rely on the CSRC to correctly identify the
stream to be paused when the delivered media is some type of mix.
A more elaborate stream identification solution is needed to
support this in the general case.
3. The End Point cannot determine if a given stream is still needed
by the RTP Mixer to deliver to another session participant.
Due to the above reasons, we exclude this use case from further
consideration.
4. Design Considerations
This section describes the requirements that this specification needs
to meet.
4.1. Real-time Nature
The first section (Section 1) of this specification describes some
possible reasons why a receiver may pause an RTP sender. Pausing and
resuming is time-dependent, i.e. a receiver may choose to pause an
RTP stream for a certain duration, after which the receiver may want
the sender to resume. This time dependency means that the messages
related to pause and resume must be transmitted to the sender in
real-time in order for them to be purposeful. The pause operation is
arguably not very time critical since it mainly provides a reduction
of resource usage. Timely handling of the resume operation is
however likely to directly impact the end-user's perceived quality
experience, since it affects the availability of media that the user
expects to receive more or less instantly.
Burman, et al. Expires January 25, 2015 [Page 10]
Internet-Draft RTP Stream Pause July 2014
4.2. Message Direction
It is the responsibility of an RTP stream receiver, who wants to
pause or resume a stream from the sender(s), to transmit PAUSE and
RESUME messages. An RTP stream sender who likes to pause itself, can
simply do it. Any indication that an RTP stream is paused is the
responsibility of the RTP stream sender and may in some cases not
even be needed by the stream receiver.
4.3. Apply to Individual Sources
The PAUSE and RESUME messages apply to single RTP streams identified
by their SSRC, which means the receiver targets the sender's SSRC in
the PAUSE and RESUME requests. If a paused sender starts sending
with a new SSRC, the receivers will need to send a new PAUSE request
in order to pause it. PAUSED indications refer to a single one of
the sender's own, paused SSRC.
4.4. Consensus
An RTP stream sender should not pause an SSRC that some receiver
still wishes to receive. The reason is that in RTP topologies where
the stream is shared between multiple receivers, a single receiver on
that shared network, independent of it being multicast, a mesh with
joint RTP session or a transport Translator based, must not single-
handedly cause the stream to be paused without letting all other
receivers to voice their opinions on whether or not the stream should
be paused. A consequence of this is that a newly joining receiver,
for example indicated by an RTCP Receiver Report containing both a
new SSRC and a CNAME that does not already occur in the session,
firstly needs to learn the existence of paused streams, and secondly
should be able to resume any paused stream. Any single receiver
wanting to resume a stream should also cause it to be resumed.
4.5. Acknowledgments
RTP and RTCP does not guarantee reliable data transmission. It uses
whatever assurance the lower layer transport protocol can provide.
However, this is commonly UDP that provides no reliability
guarantees. Thus it is possible that a PAUSE and/or RESUME message
transmitted from an RTP End Point does not reach its destination,
i.e. the targeted RTP stream sender. When PAUSE or RESUME reaches
the RTP stream sender and are effective, i.e., an active RTP stream
sender pauses, or a resuming RTP stream sender have media data to
transmit, it is immediately seen from the arrival or non-arrival of
RTP packets for that RTP stream. Thus, no explicit acknowledgments
are required in this case.
Burman, et al. Expires January 25, 2015 [Page 11]
Internet-Draft RTP Stream Pause July 2014
In some cases when a PAUSE or RESUME message reaches the RTP stream
sender, it will not be able to pause or resume the stream due to some
local consideration, for example lack of data to transmit. This
error condition, a negative acknowledgment, may be needed to avoid
unnecessary retransmission of requests (Section 4.6).
4.6. Retransmitting Requests
When the stream is not affected as expected by a PAUSE or RESUME
request, the request may have been lost and the sender of the request
will need to retransmit it. The retransmission should take the round
trip time into account, and will also need to take the normal RTCP
bandwidth and timing rules applicable to the RTP session into
account, when scheduling retransmission of feedback.
When it comes to resume requests that are more time critical, the
best resume performance may be achieved by repeating the request as
often as possible until a sufficient number have been sent to reach a
high probability of request delivery, or the stream gets delivered.
4.7. Sequence Numbering
A PAUSE request message will need to have a sequence number to
separate retransmissions from new requests. A retransmission keeps
the sequence number unchanged, while it is incremented every time a
new PAUSE request is transmitted that is not a retransmission of a
previous request.
Since RESUME always takes precedence over PAUSE and are even allowed
to avoid pausing a stream, there is a need to keep strict ordering of
PAUSE and RESUME. Thus, RESUME needs to share sequence number space
with PAUSE and implicitly references which PAUSE it refers to. For
the same reasons, the explicit PAUSED indication also needs to share
sequence number space with PAUSE and RESUME.
4.8. Relation to Other Solutions
A performance comparison between SIP/SDP and RTCP signaling
technologies was made and included in draft versions of this
specification. Using SIP and SDP [RFC4566] to carry pause and resume
information means that it will need to traverse the entire signaling
path to reach the signaling destination (either the remote End Point
or the entity controlling the RTP Mixer), across any signaling
proxies that potentially also has to process the SDP content to
determine if they are expected to act on it. The amount of bandwidth
required for a SIP/SDP-based signaling solution is in the order of at
least 10 times more than an RTCP-based solution. Especially for UA
sitting on mobile wireless access, this will risk introducing delays
Burman, et al. Expires January 25, 2015 [Page 12]
Internet-Draft RTP Stream Pause July 2014
that are too long (Section 4.1) to provide a good user experience,
and the bandwidth cost may also be considered infeasible compared to
an RTCP-based solution. RTCP data is sent through the media path,
which is likely shorter (contains fewer intermediate nodes) than the
signaling path, may anyway have to traverse a few intermediate nodes.
The amount of processing and buffering required in intermediate nodes
to forward those RTCP messages is however believed to be
significantly less than for intermediate nodes in the signaling path.
Based on those considerations, RTCP is chosen as signaling protocol
for the pause and resume functionality.
5. Solution Overview
The proposed solution implements PAUSE and RESUME functionality based
on sending AVPF RTCP feedback messages from any RTP session
participant that wants to pause or resume a stream targeted at the
stream sender, as identified by the sender SSRC.
It is proposed to re-use CCM TMMBR and TMMBN [RFC5104] to the extent
possible, and to define a small set of new RTCP feedback messages
where new semantics is needed. Considerations that apply when using
TMMBR/TMMBN for pause and resume purposes are also described.
A single Feedback message specification is used to implement the new
messages. The message consists of a number of Feedback Control
Information (FCI) blocks, where each block can be a PAUSE request, a
RESUME request, PAUSED indication, a REFUSE response, or an extension
to this specification. This structure allows a single feedback
message to handle pause functionality on a number of streams.
The PAUSED functionality is also defined in such a way that it can be
used standalone by the RTP stream sender to indicate a local decision
to pause, and inform any receiver of the fact that halting media
delivery is deliberate and which RTP packet was the last transmitted.
This section is intended to be explanatory and therefore
intentionally contains no mandatory statements. Such statements can
instead be found in other parts of this specification.
5.1. Expressing Capability
An End Point can use an extension to CCM SDP signaling to declare
capability to understand the messages defined in this specification.
Capability to understand PAUSED indication is defined separately from
the others to support partial implementation, which is specifically
believed to be feasible for the RTP Mixer to Media Sender use case
(Section 3.2).
Burman, et al. Expires January 25, 2015 [Page 13]
Internet-Draft RTP Stream Pause July 2014
For the case when TMMBR/TMMBN are used for pause and resume purposes,
it is possible to explicitly express joint support for TMMBR and
TMMBN, but not for TMMBN only.
5.2. Requesting to Pause
An RTP stream receiver can choose to request PAUSE at any time,
subject to AVPF timing rules. This also applies when using TMMBR 0
in the point-to-point case.
The PAUSE request contains a PauseID, which is incremented by one (in
modulo arithmetic) with each PAUSE request that is not a re-
transmission. The PauseID is scoped by and thus a property of the
targeted RTP stream (SSRC).
When a non-paused RTP stream sender receives the PAUSE request, it
continues to send the RTP stream while waiting for some time to allow
other RTP stream receivers in the same RTP session that saw this
PAUSE request to disapprove by sending a RESUME (Section 5.4) for the
same stream and with the same PauseID as in the disapproved PAUSE.
If such disapproving RESUME arrives at the RTP stream sender during
the wait period before the stream is paused, the pause is not
performed. In point-to-point configurations, the wait period may be
set to zero. Using a wait period of zero is also appropriate when
using TMMBR 0 and in line with the semantics for that message.
If the RTP stream sender receives further PAUSE requests with the
available PauseID while waiting as described above, those additional
requests are ignored.
If the PAUSE request or TMMBR 0 is lost before it reaches the RTP
stream sender, it will be discovered by the RTP stream receiver
because it continues to receive the RTP stream. It will also not see
any PAUSED indication (Section 5.3) or TMMBN 0 for the stream. The
same condition can be caused by the RTP stream sender having received
a disapproving RESUME from a stream receiver A for a PAUSE request
sent by a stream sender B, but that the PAUSE sender (B) did not
receive the RESUME (from A) and may instead think that the PAUSE was
lost. In both cases, a PAUSE request can be re-transmitted using the
same PauseID. If using TMMBR 0 the request MAY be re-transmitted
when the requester fails to receive a TMMBN 0 confirmation.
If the pending stream pause is aborted due to a disapproving RESUME,
the PauseID from the disapproved PAUSE is invalidated by the RESUME
and any new PAUSE must use an incremented PauseID (in modulo
arithmetic) to be effective.
Burman, et al. Expires January 25, 2015 [Page 14]
Internet-Draft RTP Stream Pause July 2014
An RTP stream sender receiving a PAUSE not using the available
PauseID informs the RTP stream receiver sending the ineffective PAUSE
of this condition by sending a REFUSE response that contains the next
available PauseID value. This REFUSE also informs the RTP stream
receiver that it is probably not feasible to send another PAUSE for
some time, not even with the available PauseID, since there are other
RTP stream receivers that wish to receive the stream.
A similar situation where an ineffective PauseID is chosen can appear
when a new RTP stream receiver joins a session and wants to PAUSE a
stream, but does not yet know the available PauseID to use. The
REFUSE response will then provide sufficient information to create a
valid PAUSE. The required extra signaling round-trip is not
considered harmful, since it is assumed that pausing a stream is not
time-critical (Section 4.1).
There may be local considerations making it impossible or infeasible
to pause the stream, and the RTP stream sender can then respond with
a REFUSE. In this case, if the used PauseID would otherwise have
been effective, the REFUSE contains the same PauseID as in the PAUSE
request, and the PauseID is kept as available. Note that when using
TMMBR 0 as PAUSE, that request cannot be refused (TMMBN > 0) due to
the existing restriction in section 4.2.2.2 of [RFC5104] that TMMBN
SHALL contain the current bounding set, and the fact that a TMMBR 0
will always be the most restrictive point in any bounding set.
If the RTP stream sender receives several identical PAUSE for an RTP
stream that was already at least once responded with REFUSE and the
condition causing REFUSE remains, those additional REFUSE should be
sent with regular RTCP timing. A single REFUSE can respond to
several identical PAUSE requests.
5.3. Media Sender Pausing
An RTP stream sender can choose to pause the stream at any time.
This can either be as a result of receiving a PAUSE, or be based on
some local sender consideration. When it does, it sends a PAUSED
indication, containing the available PauseID. If the stream was
paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication. What is
said on PAUSED in the rest of this paragraph apply also to the use of
TMMBN 0, except for PAUSED message parameters. Note that PauseID is
incremented when pausing locally (without having received a PAUSE).
It also sends the PAUSED indication in the next two regular RTCP
reports, given that the pause condition is then still effective.
The RTP stream sender may want to apply some local consideration to
exactly when the stream is paused, for example completing some media
unit or a forward error correction block, before pausing the stream.
Burman, et al. Expires January 25, 2015 [Page 15]
Internet-Draft RTP Stream Pause July 2014
+-----------+------+--------+---------------+--------+--------------+
| Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 |
| | src | | parent) | | |
+-----------+------+--------+---------------+--------+--------------+
| Inserted | RPI | -- | -- | -- | -- |
| headers | | | | | |
| Removed | -- | -- | -- | -- | RPI |
| headers | | | | | |
| Re-added | -- | -- | -- | -- | -- |
| headers | | | | | |
| Modified | -- | RPI | RPI | RPI | -- |
| headers | | | | | |
| Untouched | -- | -- | -- | -- | RPI(Ignored) |
| headers | | | | | |
+-----------+------+--------+---------------+--------+--------------+
Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
aware-leaf
5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf
In this case the flow comprises:
not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) -->
6LR_id --> 6LN
6LR_ia are the intermediate routers from source (not-RPL-aware 6LN
(IPv6)) to the common parent (6LR_x) In this case, "1 <= ia >= n", n
is the number of routers (6LR) that the packet go through from source
to the common parent.
6LR_id are the intermediate routers from the common parent (6LR_x) to
destination 6LN. In this case, "1 <= id >= m", m is the number of
routers (6LR) that the packet go through from the common parent
(6LR_x) to destination 6LN.
The 6LR_ia (ia=1) receives the packet from the the IPv6 node and
inserts and the RPI header encapsulated in IPv6-in-IPv6 header. The
IP-in-IP header is addressed to the destination 6LN.
Robles, et al. Expires October 5, 2017 [Page 18]
Internet-Draft Useof6553 April 2017
+--------+------+------------+------------+------------+------------+
| Header | IPv6 | 6LR_ia | common | 6LR_id | 6LN |
| | | | parent | | |
| | | | (6LRx) | | |
+--------+------+------------+------------+------------+------------+
| Insert | -- | IP-in- | -- | -- | -- |
| ed hea | | IP(RPI) | | | |
| ders | | | | | |
| Remove | -- | -- | -- | -- | IP-in- |
| d head | | | | | IP(RPI) |
| ers | | | | | |
| Re- | -- | -- | -- | -- | -- |
| added | | | | | |
| header | | | | | |
| s | | | | | |
| Modifi | -- | -- | IP-in- | IP-in- | -- |
| ed hea | | | IP(RPI) | IP(RPI) | |
| ders | | | | | |
| Untouc | -- | -- | -- | -- | -- |
| hed he | | | | | |
| aders | | | | | |
+--------+------+------------+------------+------------+------------+
Storing: Summary of the use of headers from not-RPL-aware-leaf to
RPL-aware-leaf
5.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-leaf
In this case the flow comprises:
not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> root (6LBR) -->
6LR_id --> not-RPL-aware 6LN (IPv6 dst)
6LR_ia are the intermediate routers from source (not-RPL-aware 6LN
(IPv6 src)) to the root (6LBR) In this case, "1 < ia >= n", n is the
number of routers (6LR) that the packet go through from IPv6 src to
the root.
6LR_id are the intermediate routers from the root to destination
(IPv6 dst). In this case, "1 <= id >= m", m is the number of routers
(6LR) that the packet go through from the root to destination (IPv6
dst).
This flow is identical to Section 5.11
The 6LR_1 receives the packet from the the IPv6 node and inserts the
RPI header (RPIa) encapsulated in IPv6-in-IPv6 header. The IPv6-in-
IPv6 header is addressed to the 6LBR. The 6LBR remove the IPv6-in-
Robles, et al. Expires October 5, 2017 [Page 19]
Internet-Draft Useof6553 April 2017
IPv6 header and insert another one (RPIb) with destination to 6LR_m
node.
One of the side-effects of inserting IP-in-IP RPI header at 6LR_1, is
that now all the packets will go through the 6LBR, even though there
exists a shorter P2P path to the destination 6LN in storing mode.
One possible solution is given by the work in
[I-D.ietf-roll-dao-projection]. Once we have route projection, the
root can find that this traffic deserves optimization (based on
volume and path length, or additional knowledge on that particular
flow) and project a DAO into 6LR_1.
+-------+-----+-----------+-----------+-----------+-----------+-----+
| Heade | IPv | 6LR_1 | 6LR_ia | 6LBR | 6LR_m | IPv |
| r | 6 | | | | | 6 |
| | src | | | | | dst |
+-------+-----+-----------+-----------+-----------+-----------+-----+
| Inser | -- | IP-in- | -- | IP-in- | -- | -- |
| ted h | | IP(RPI_a) | | IP(RPI_b) | | |
| eader | | | | | | |
| s | | | | | | |
| Remov | -- | -- | -- | -- | -- | -- |
| ed he | | | | | | |
| aders | | | | | | |
| Re- | -- | -- | -- | -- | IP-in- | -- |
| added | | | | | IP(RPI_b) | |
| heade | | | | | | |
| rs | | | | | | |
| Modif | -- | -- | IP-in- | -- | IP-in- | -- |
| ied h | | | IP(RPI_a) | | IP(RPI_b) | |
| eader | | | | | | |
| s | | | | | | |
| Untou | -- | -- | -- | -- | -- | -- |
| ched | | | | | | |
| heade | | | | | | |
| rs | | | | | | |
+-------+-----+-----------+-----------+-----------+-----------+-----+
Storing: Summary of the use of headers from not-RPL-aware-leaf to
non-RPL-aware-leaf
6. Non Storing mode
Robles, et al. Expires October 5, 2017 [Page 20]
Internet-Draft Useof6553 April 2017
+--------------+------+------+-----------+---------------+
| Use Case | RPI | RH3 | IP-in-IP | IP-in-IP dst |
+--------------+------+------+-----------+---------------+
| Raf to root | Yes | No | No | -- |
| root to Raf | Opt | Yes | No | -- |
| root to ~Raf | No | Yes | Yes | 6LR |
| ~Raf to root | Yes | No | Yes | root |
| Raf to Int | Yes | No | Yes | root |
| Int to Raf | Opt | Yes | Yes | dst |
| ~Raf to Int | Yes | No | Yes | root |
| Int to ~Raf | Opt | Yes | Yes | 6LR |
| Raf to Raf | Yes | Yes | Yes | root/dst |
| Raf to ~Raf | Yes | Yes | Yes | root/6LR |
| ~Raf to Raf | Yes | Yes | Yes | root/6LN |
| ~Raf to ~Raf | Yes | Yes | Yes | root/6LR |
+--------------+------+------+-----------+---------------+
Table 2: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP
encapsulation
6.1. Example of Flow from RPL-aware-leaf to root
In non-storing mode the leaf node uses default routing to send
traffic to the root. The RPI header must be included to avoid/detect
loops.
RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR)
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from source (6LN) to destination (6LBR).
This situation is the same case as storing mode.
+-------------------+-----+-------+------+
| Header | 6LN | 6LR_i | 6LBR |
+-------------------+-----+-------+------+
| Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | RPI |
| Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | -- |
+-------------------+-----+-------+------+
Non Storing: Summary of the use of headers from RPL-aware-leaf to
root
Robles, et al. Expires October 5, 2017 [Page 21]
Internet-Draft Useof6553 April 2017
6.2. Example of Flow from root to RPL-aware-leaf
In this case the flow comprises:
root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from source (6LBR) to destination (6LN).
The 6LBR will insert an RH3, and may optionally insert an RPI header.
No IP-in-IP header is necessary as the traffic originates with an RPL
aware node, the 6LBR. The destination is known to RPL-aware because,
the root knows the whole topology in non-storing mode.
+-------------------+-----------------+-------+----------+
| Header | 6LBR | 6LR_i | 6LN |
+-------------------+-----------------+-------+----------+
| Inserted headers | (opt: RPI), RH3 | -- | -- |
| Removed headers | -- | -- | RH3,RPI |
| Re-added headers | -- | -- | -- |
| Modified headers | -- | RH3 | -- |
| Untouched headers | -- | -- | -- |
+-------------------+-----------------+-------+----------+
Non Storing: Summary of the use of headers from root to RPL-aware-
leaf
6.3. Example of Flow from root to not-RPL-aware-leaf
In this case the flow comprises:
root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from source (6LBR) to destination (IPv6).
In 6LBR the RH3 is added, modified in each intermediate 6LR (6LR_1
and so on) and it is fully consumed in the last 6LR (6LR_n), but left
there. If RPI is left present, the IPv6 node which does not
understand it will ignore it (following 2460bis), thus encapsulation
is not necesary. Due the complete knowledge of the topology at the
root, the 6LBR is able to address the IP-in-IP header to the last
6LR.
Robles, et al. Expires October 5, 2017 [Page 22]
Internet-Draft Useof6553 April 2017
The PAUSED indication also contains information about the RTP
extended highest sequence number when the pause became effective.
This provides RTP stream receivers with first hand information
allowing them to know whether they lost any packets just before the
stream paused or when the stream is resumed again. This allows RTP
stream receivers to quickly and safely take into account that the
stream is paused, in for example retransmission or congestion control
algorithms.
If the RTP stream sender receives PAUSE requests with the available
PauseID while the stream is already paused, those requests are
ignored.
As long as the stream is being paused, the PAUSED indication MAY be
sent together with any regular RTCP SR or RR. Including PAUSED in
this way allows RTP stream receivers joining while the stream is
paused to quickly know that there is a paused stream, what the last
sent extended RTP sequence number was, and what the next available
PauseID is to be able to construct valid PAUSE and RESUME requests at
a later stage.
When the RTP stream sender learns that a new End Point has joined the
RTP session, for example by a new SSRC and a CNAME that was not
previously seen in the RTP session, it should send PAUSED indications
for all its paused streams at its earliest opportunity. It should in
addition continue to include PAUSED indications in at least two
regular RTCP reports.
5.4. Requesting to Resume
An RTP stream receiver can request to resume a stream with a RESUME
request at any time, subject to AVPF timing rules. If the stream was
paused with TMMBR 0, resuming the stream is made with TMMBR
containing a bitrate value larger than 0. The bitrate value used
when resuming after a PAUSE with TMMBR 0 is either according to known
limitations, or the configured maximum for the stream or session.
What is said on RESUME in the rest of this paragraph apply also to
the use of TMMBR with a bitrate value larger than 0, except for
RESUME message parameters.
The RTP stream receiver must include the available PauseID in the
RESUME request for it to be effective.
A pausing RTP stream sender that receives a RESUME including the
correct available PauseID resumes the stream at the earliest
opportunity. Receiving RESUME requests for a stream that is not
paused does not require any action and can be ignored.
Burman, et al. Expires January 25, 2015 [Page 16]
Internet-Draft RTP Stream Pause July 2014
There may be local considerations, for example that the media device
is not ready, making it temporarily impossible to resume the stream
at that point in time, and the RTP stream sender MAY then respond
with a REFUSE containing the same PauseID as in the RESUME. When
receiving such REFUSE with a PauseID identical to the one in the sent
RESUME, RTP stream receivers SHOULD then avoid sending further RESUME
requests for some reasonable amount of time, to allow the condition
to clear.
If the RTP stream sender receives several identical RESUME for an RTP
stream that was already at least once responded with REFUSE and the
condition causing REFUSE remains, those additional REFUSE should be
sent with regular RTCP timing. A single REFUSE can respond to
several identical RESUME requests.
When resuming a paused stream, especially for media that makes use of
temporal redundancy between samples such as video, the temporal
dependency between samples taken before the pause and at the time
instant the stream is resumed may not be appropriate to use in the
encoding. Should such temporal dependency between before and after
the media was paused be used by the RTP stream sender, it requires
the RTP stream receiver to have saved the sample from before the
pause for successful continued decoding when resuming. The use of
this temporal dependency is left up to the RTP stream sender. If
temporal dependency is not used when the RTP stream is resumed, the
first encoded sample after the pause will not contain any temporal
dependency to samples before the pause (for video it may be a so-
called intra picture). If temporal dependency to before the pause is
used by the RTP stream sender when resuming, and if the RTP stream
receiver did not save any sample from before the pause, the RTP
stream receiver can use a FIR request [RFC5104] to explicitly ask for
a sample without temporal dependency (for video a so-called intra
picture), even at the same time as sending the RESUME.
5.5. TMMBR/TMMBN Considerations
As stated, TMMBR/TMMBN may be used to provide pause and resume
functionality for the point-to-point case. If the topology is not
point-to-point, TMMBR/TMMBN cannot safely be used for pause or
resume.
This is a brief summary of what functionality is provided when using
TMMBR/TMMBN:
TMMBR 0: Corresponds to PAUSE, without the requirement for any hold-
off period to wait for RESUME before pausing the stream.
Burman, et al. Expires January 25, 2015 [Page 17]
Internet-Draft RTP Stream Pause July 2014
TMMBR >0: Corresponds to RESUME when the stream was previously
paused with TMMBR 0. Since there is only a single RTP stream
receiver, there is no need for the RTP stream sender to delay
resuming the stream until after sending TMMBN >0, or to apply the
hold-off period specified in [RFC5104] before increasing the
bitrate from zero.
TMMBN 0: Corresponds to PAUSED. Also corresponds to a REFUSE
indication when a stream is requested to be resumed with TMMBR >0.
TMMBN >0: Cannot be used as REFUSE indication when a stream is
requested to be paused with TMMBR 0, for reasons stated in
Section 5.2.
6. Participant States
This document introduces three new states for a stream in an RTP
sender, according to the figure and sub-sections below. Any
references to PAUSE, PAUSED, RESUME and REFUSE in this section SHALL
be taken to apply to the extent possible also when TMMBR/TMMBN are
used (Section 5.5) for this functionality.
+------------------------------------------------------+
| Received RESUME |
v |
+---------+ Received PAUSE +---------+ Hold-off period +--------+
| Playing |---------------->| Pausing |---------------->| Paused |
| |<----------------| | | |
+---------+ Received RESUME +---------+ +--------+
^ | | PAUSE decision |
| | v |
| | PAUSE decision +---------+ PAUSE decision |
| +------------------>| Local |<--------------------+
+-------------------------| Paused |
RESUME decision +---------+
Figure 4: RTP Pause States
6.1. Playing State
This state is not new, but is the normal media sending state from
[RFC3550]. When entering the state, the PauseID MUST be incremented
by one in modulo arithmetic. The RTP sequence number for the first
packet sent after a pause SHALL be incremented by one compared to the
highest RTP sequence number sent before the pause. The first RTP
Time Stamp for the first packet sent after a pause SHOULD be set
according to capture times at the source.
Burman, et al. Expires January 25, 2015 [Page 18]
Internet-Draft RTP Stream Pause July 2014
6.2. Pausing State
In this state, the RTP stream sender has received at least one PAUSE
message for the stream in question. The RTP stream sender SHALL wait
during a hold-off period for the possible reception of RESUME
messages for the RTP stream being paused before actually pausing RTP
stream transmission. The period to wait SHALL be long enough to
allow another RTP stream receiver to respond to the PAUSE with a
RESUME, if it determines that it would not like to see the stream
paused. This delay period (denoted by 'Hold-off period' in the
figure) is determined by the formula:
2 * RTT + T_dither_max,
where RTT is the longest round trip known to the RTP stream sender
and T_dither_max is defined in section 3.4 of [RFC4585]. The hold-
off period MAY be set to 0 by some signaling (Section 9) means when
it can be determined that there is only a single receiver, for
example in point-to-point or some unicast situations.
If the RTP stream sender has set the hold-off period to 0 and
receives information that it was an incorrect decision and that there
are in fact several receivers of the stream, for example by RTCP RR,
it MUST change the hold-off to instead be based on the above formula.
6.3. Paused State
An RTP stream is in paused state when the sender pauses its
transmission after receiving at least one PAUSE message and the hold-
off period has passed without receiving any RESUME message for that
stream.
When entering the state, the RTP stream sender SHALL send a PAUSED
indication to all known RTP stream receivers, and SHALL also repeat
PAUSED in the next two regular RTCP reports.
Following sub-sections discusses some potential issues when an RTP
sender goes into paused state. These conditions are also valid if an
RTP Translator is used in the communication. When an RTP Mixer
implementing this specification is involved between the participants
(which forwards the stream by marking the RTP data with its own
SSRC), it SHALL be a responsibility of the Mixer to control sending
PAUSE and RESUME requests to the sender. The below conditions also
apply to the sender and receiver parts of the RTP Mixer,
respectively.
Burman, et al. Expires January 25, 2015 [Page 19]
Internet-Draft RTP Stream Pause July 2014
6.3.1. RTCP BYE Message
When a participant leaves the RTP session, it sends an RTCP BYE
message. In addition to the semantics described in section 6.3.4 and
6.3.7 of RTP [RFC3550], following two conditions MUST also be
considered when an RTP participant sends an RTCP BYE message,
o If a paused sender sends an RTCP BYE message, receivers observing
this SHALL NOT send further PAUSE or RESUME requests to it.
o Since a sender pauses its transmission on receiving the PAUSE
requests from any receiver in a session, the sender MUST keep
record of which receiver that caused the RTP stream to pause. If
that receiver sends an RTCP BYE message observed by the sender,
the sender SHALL resume the RTP stream.
6.3.2. SSRC Time-out
Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP
participant. Every RTP participant maintains a sender and receiver
list in a session. If a participant does not get any RTP or RTCP
packets from some other participant for the last five RTCP reporting
intervals it removes that participant from the receiver list. Any
streams that were paused by that removed participant SHALL be
resumed.
6.4. Local Paused State
This state can be entered at any time, based on local decision from
the RTP stream sender. As for Paused State (Section 6.3), the RTP
stream sender SHALL send a PAUSED indication to all known RTP stream
receivers, when entering the state, and repeat it in the next two
regular RTCP reports.
When leaving the state, the stream state SHALL become Playing,
regardless whether or not there were any RTP stream receivers that
sent PAUSE for that stream, effectively clearing the RTP stream
sender's memory for that stream.
7. Message Format
Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP
feedback messages, i.e. Transport layer, Payload-specific, and
Application layer feedback messages. This document defines a new
Transport layer feedback message, this message is either a PAUSE
request, a RESUME request, or one of four different types of
acknowledgments in response to either PAUSE or RESUME requests.
Burman, et al. Expires January 25, 2015 [Page 20]
Internet-Draft RTP Stream Pause July 2014
The Transport layer feedback messages are identified by having the
RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. The
PAUSE and RESUME messages are identified by Feedback Message Type
(FMT) value in common packet header for feedback message defined in
section 6.1 of AVPF [RFC4585]. The PAUSE and RESUME transport
feedback message is identified by the FMT value = TBA1.
The Common Packet Format for Feedback Messages defined by AVPF
[RFC4585] is:
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=2|P| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
For the PAUSE and RESUME messages, the following interpretation of
the packet fields will be:
FMT: The FMT value identifying the PAUSE and RESUME message: TBA1
PT: Payload Type = 205 (RTPFB)
Length: As defined by AVPF, i.e. the length of this packet in 32-bit
words minus one, including the header and any padding.
SSRC of packet sender: The SSRC of the RTP session participant
sending the messages in the FCI. Note, for End Points that have
multiple SSRCs in an RTP session, any of its SSRCs MAY be used to
send any of the pause message types.
SSRC of media source: Not used, SHALL be set to 0. The FCI
identifies the SSRC the message is targeted for.
The Feedback Control Information (FCI) field consist of one or more
PAUSE, RESUME, PAUSED, REFUSE, or any future extension. These
messages have the following FCI format:
Burman, et al. Expires January 25, 2015 [Page 21]
Internet-Draft RTP Stream Pause July 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Res | Parameter Len | PauseID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Type Specific :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Syntax of FCI Entry in the PAUSE and RESUME message
The FCI fields have the following definitions:
Target SSRC (32 bits): For a PAUSE and RESUME messages, this value
is the SSRC that the request is intended for. For PAUSED, it MUST
be the SSRC being paused. If pausing is the result of a PAUSE
request, the value in PAUSED is effectively the same as Target
SSRC in a related PAUSE request. For REFUSE, it MUST be the
Target SSRC of the PAUSE or RESUME request that cannot change
state. A CSRC MUST NOT be used as a target as the interpretation
of such a request is unclear.
Type (4 bits): The pause feedback type. The values defined in this
specification are as follows,
0: PAUSE request message
1: RESUME request message
2: PAUSED indication message
3: REFUSE indication message
4-15: Reserved for future use
Res: (4 bits): Type specific reserved. SHALL be ignored by
receivers implementing this specification and MUST be set to 0 by
senders implementing this specification.
Parameter Len: (8 bits): Length of the Type Specific field in 32-bit
words. MAY be 0.
PauseID (16 bits): Message sequence identification. SHALL be
incremented by one modulo 2^16 for each new PAUSE message, unless
the message is re-transmitted. The initial value SHOULD be 0.
The PauseID is scoped by the Target SSRC, meaning that PAUSE,
+---------------+-------------+---------------+--------------+------+
| Header | 6LBR | 6LR_i(i=1) | 6LR_n(i=n) | IPv6 |
+---------------+-------------+---------------+--------------+------+
| Inserted | (opt: RPI), | -- | -- | -- |
| headers | RH3 | | | |
| Removed | -- | RH3 | -- | -- |
| headers | | | | |
| Re-added | -- | -- | -- | -- |
| headers | | | | |
| Modified | -- | (opt: RPI), | (opt: RPI), | -- |
| headers | | RH3 | RH3 | |
| Untouched | -- | -- | -- | RPI |
| headers | | | | |
+---------------+-------------+---------------+--------------+------+
Non Storing: Summary of the use of headers from root to not-RPL-
aware-leaf
6.4. Example of Flow from not-RPL-aware-leaf to root
In this case the flow comprises:
not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR)
6LR_i are the intermediate routers from source to destination. In
this case, "1 < i >= n", n is the number of routers (6LR) that the
packet go through from source (IPv6) to destination (6LBR). For
example, 6LR_1 (i=1) is the router that receives the packets from the
IPv6 node.
In this case the RPI is added by the first 6LR (6LR1), encapsulated
in an IP-in-IP header, and is modified in the followings 6LRs. The
RPI and entire packet is consumed by the root.
Robles, et al. Expires October 5, 2017 [Page 23]
Internet-Draft Useof6553 April 2017
+------------+------+---------------+---------------+---------------+
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |
+------------+------+---------------+---------------+---------------+
| Inserted | -- | IP-in-IP(RPI) | -- | -- |
| headers | | | | |
| Removed | -- | -- | -- | IP-in-IP(RPI) |
| headers | | | | |
| Re-added | -- | -- | -- | -- |
| headers | | | | |
| Modified | -- | -- | IP-in-IP(RPI) | -- |
| headers | | | | |
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+------------+------+---------------+---------------+---------------+
Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
root
6.5. Example of Flow from RPL-aware-leaf to Internet
In this case the flow comprises:
RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from source (6LN) to 6LBR.
This case is identical to storing-mode case.
The IPv6 flow label should be set to zero to aid in compression, and
the 6LBR will set it to a non-zero value when sending towards the
Internet.
+-------------------+------+-------+------+----------------+
| Header | 6LN | 6LR_i | 6LBR | Internet |
+-------------------+------+-------+------+----------------+
| Inserted headers | RPI | -- | -- | -- |
| Removed headers | -- | -- | -- | -- |
| Re-added headers | -- | -- | -- | -- |
| Modified headers | -- | RPI | -- | -- |
| Untouched headers | -- | -- | RPI | RPI (Ignored) |
+-------------------+------+-------+------+----------------+
Non Storing: Summary of the use of headers from RPL-aware-leaf to
Internet
Robles, et al. Expires October 5, 2017 [Page 24]
Internet-Draft Useof6553 April 2017
6.6. Example of Flow from Internet to RPL-aware-leaf
In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from 6LBR to destination(6LN).
The 6LBR must add an RH3 header. As the 6LBR will know the path and
address of the target node, it can address the IP-in-IP header to
that node. The 6LBR will zero the flow label upon entry in order to
aid compression.
The RPI may be added or not, it is optional.
+--------+-------+----------------+----------------+----------------+
| Header | Inter | 6LBR | 6LR_i | 6LN |
| | net | | | |
+--------+-------+----------------+----------------+----------------+
| Insert | -- | IP-in-IP(RH3,o | -- | -- |
| ed hea | | pt:RPI) | | |
| ders | | | | |
| Remove | -- | -- | -- | IP-in-IP(RH3,o |
| d head | | | | pt:RPI) |
| ers | | | | |
| Re- | -- | -- | -- | -- |
| added | | | | |
| header | | | | |
| s | | | | |
| Modifi | -- | -- | IP-in-IP(RH3,o | -- |
| ed hea | | | pt:RPI) | |
| ders | | | | |
| Untouc | -- | -- | -- | -- |
| hed he | | | | |
| aders | | | | |
+--------+-------+----------------+----------------+----------------+
Non Storing: Summary of the use of headers from Internet to RPL-
aware-leaf
6.7. Example of Flow from not-RPL-aware-leaf to Internet
In this case the flow comprises:
not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) -->
Internet
Robles, et al. Expires October 5, 2017 [Page 25]
Internet-Draft Useof6553 April 2017
6LR_i are the intermediate routers from source to destination. In
this case, "1 < i >= n", n is the number of routers (6LR) that the
packet go through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1).
In this case the flow label is recommended to be zero in the IPv6
node. As RPL headers are added in the IPv6 node, the first 6LR
(6LR_1) will add an RPI header inside a new IP-in-IP header. The IP-
in-IP header will be addressed to the root. This case is identical
to the storing-mode case (Section 5.7).
+---------+-----+-------------+-------------+-------------+---------+
| Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne |
| | 6 | | [i=2,..,n]_ | | t |
+---------+-----+-------------+-------------+-------------+---------+
| Inserte | -- | IP-in- | -- | -- | -- |
| d | | IP(RPI) | | | |
| headers | | | | | |
| Removed | -- | -- | -- | IP-in- | -- |
| headers | | | | IP(RPI) | |
| Re- | -- | -- | -- | -- | -- |
| added | | | | | |
| headers | | | | | |
| Modifie | -- | -- | IP-in- | -- | -- |
| d | | | IP(RPI) | | |
| headers | | | | | |
| Untouch | -- | -- | -- | -- | -- |
| ed | | | | | |
| headers | | | | | |
+---------+-----+-------------+-------------+-------------+---------+
Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
Internet
6.8. Example of Flow from Internet to not-RPL-aware-leaf
In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
6LR_i are the intermediate routers from source to destination. In
this case, "1 < i >= n", n is the number of routers (6LR) that the
packet go through from 6LBR to not-RPL-aware-leaf (IPv6).
The 6LBR must add an RH3 header inside an IP-in-IP header. The 6LBR
will know the path, and will recognize that the final node is not an
RPL capable node as it will have received the connectivity DAO from
the nearest 6LR. The 6LBR can therefore make the IP-in-IP header
Robles, et al. Expires October 5, 2017 [Page 26]
Internet-Draft Useof6553 April 2017
destination be the last 6LR. The 6LBR will set to zero the flow
label upon entry in order to aid compression.
+--------+-------+----------------+------------+-------------+------+
| Header | Inter | 6LBR | 6LR_1 | 6LR_i(i=2,. | IPv6 |
| | net | | | .,n) | |
+--------+-------+----------------+------------+-------------+------+
| Insert | -- | IP-in-IP(RH3,o | -- | -- | -- |
| ed hea | | pt:RPI) | | | |
| ders | | | | | |
| Remove | -- | -- | -- | IP-in- | -- |
| d head | | | | IP(RH3, | |
| ers | | | | RPI) | |
| Re- | -- | -- | -- | -- | -- |
| added | | | | | |
| header | | | | | |
| s | | | | | |
| Modifi | -- | -- | IP-in- | IP-in- | -- |
| ed hea | | | IP(RH3, | IP(RH3, | |
| ders | | | RPI) | RPI) | |
| Untouc | -- | -- | -- | -- | RPI |
| hed he | | | | | |
| aders | | | | | |
+--------+-------+----------------+------------+-------------+------+
NonStoring: Summary of the use of headers from Internet to non-RPL-
aware-leaf
6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf
In this case the flow comprises:
6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst
6LR_ia are the intermediate routers from source to the root In this
case, "1 <= ia >= n", n is the number of routers (6LR) that the
packet go through from 6LN to the root.
6LR_id are the intermediate routers from the root to the destination.
In this case, "1 <= ia >= m", m is the number of the intermediate
routers (6LR).
This case involves only nodes in same RPL Domain. The originating
node will add an RPI header to the original packet, and send the
packet upwards.
The originating node SHOULD put the RPI into an IP-in-IP header
addressed to the root, so that the 6LBR can remove that header. If
Robles, et al. Expires October 5, 2017 [Page 27]
Internet-Draft Useof6553 April 2017
Burman, et al. Expires January 25, 2015 [Page 22]
Internet-Draft RTP Stream Pause July 2014
RESUME, and PAUSED messages therefore share the same PauseID space
for a specific Target SSRC.
Type Specific: (variable): Defined per pause feedback Type. MAY be
empty.
8. Message Details
This section contains detailed explanations of each message defined
in this specification. All transmissions of request and indications
are governed by the transmission rules as defined by Section 8.5.
Any references to PAUSE, PAUSED, RESUME and REFUSE in this section
SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
are used (Section 5.5) for this functionality. TMMBR/TMMBN MAY be
used instead of the messages defined in this specification when the
effective topology is point-to-point. If either sender or receiver
learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
be used for pause/resume functionality. If the messages defined in
this specification are supported in addition to TMMBR/TMMBN, pause/
resume signaling MUST revert to use those instead. If the topology
is not point-to-point and the messages defined in this specification
are not supported, pause/resume functionality with TMMBR/TMMBN MUST
NOT be used.
8.1. PAUSE
An RTP stream receiver MAY schedule PAUSE for transmission at any
time.
PAUSE has no defined Type Specific parameters and Parameter Len MUST
be set to 0.
PauseID SHOULD be the available PauseID, as indicated by PAUSED
(Section 8.2) or implicitly determined by previously received PAUSE
or RESUME (Section 8.3) requests. A randomly chosen PauseID MAY be
used if it was not possible to retrieve PauseID information, in which
case the PAUSE will either succeed, or the correct PauseID can be
found in the returned REFUSE (Section 8.4). A PauseID that is
matching the available PauseID is henceforth also called a valid
PauseID.
PauseID needs to be incremented by one, in modulo arithmetic, for
each PAUSE request that is not a retransmission, compared to what was
used in the last PAUSED indication sent by the media sender. This is
to ensure that the PauseID matches what is the current available
PauseID at the RTP stream sender. The RTP stream sender increments
Burman, et al. Expires January 25, 2015 [Page 23]
Internet-Draft RTP Stream Pause July 2014
what it considers to be the available PauseID when entering Playing
State (Section 6.1).
For the scope of this specification, a PauseID larger than the
current one is defined as having a value between and including
(PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16, where "MOD" is
the modulo operator. Similarly, a PauseID smaller than the current
one is defined as having a value between and including (PauseID -
2^15) MOD 2^16 and (PauseID - 1) MOD 2^16.
If an RTP stream receiver that sent a PAUSE with a certain PauseID
receives a RESUME with the same PauseID, it is RECOMMENDED that it
refrains from sending further PAUSE requests for some appropriate
time since the RESUME indicates that there are other receivers that
still wishes to receive the stream.
If the targeted RTP stream does not pause, if no PAUSED indication
with a larger PauseID than the one used in PAUSE, and if no REFUSE is
received within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled
for retransmission, using the same PauseID. RTT is the observed
round-trip to the RTP stream sender and T_dither_max is defined in
section 3.4 of [RFC4585].
When an RTP stream sender in Playing State (Section 6.1) receives a
valid PAUSE, and unless local considerations currently makes it
impossible to pause the stream, it SHALL enter Pausing State
(Section 6.2) when reaching an appropriate place to pause in the
stream, and act accordingly.
If an RTP stream sender receives a valid PAUSE while in Pausing,
Paused (Section 6.3) or Local Paused (Section 6.4) States, the
received PAUSE SHALL be ignored.
8.2. PAUSED
The PAUSED indication MAY be sent either as a result of a valid PAUSE
(Section 8.1) request, when entering Paused State (Section 6.3), or
based on a RTP stream sender local decision, when entering Local
Paused State (Section 6.4).
PauseID MUST contain the available, valid value to be included in a
subsequent RESUME (Section 8.3).
PAUSED SHALL contain a 32 bit parameter with the RTP extended highest
sequence number valid when the RTP stream was paused. Parameter Len
MUST be set to 1.
Burman, et al. Expires January 25, 2015 [Page 24]
Internet-Draft RTP Stream Pause July 2014
After having entered Paused or Local Paused State and thus having
sent PAUSED once, PAUSED MUST also be included in the next two
regular RTCP reports, given that the pause condition is then still
effective.
While remaining in Paused or Local Paused States, PAUSED MAY be
included in all regular RTCP reports.
When in Paused or Local Paused States, It is RECOMMENDED to send
PAUSED at the earliest opportunity and also to include it in the next
two regular RTCP reports, whenever the RTP stream sender learns that
there are End Points that did not previously receive the stream, for
example by RTCP reports with an SSRC and a CNAME that was not
previously seen in the RTP session.
8.3. RESUME
An RTP stream receiver MAY schedule RESUME for transmission whenever
it wishes to resume a paused stream, or to disapprove a stream from
being paused.
PauseID SHOULD be the valid PauseID, as indicated by PAUSED
(Section 8.2) or implicitly determined by previously received PAUSE
(Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be
used if it was not possible to retrieve PauseID information, in which
case the RESUME will either succeed, or the correct PauseID can be
found in a returned REFUSE (Section 8.4).
RESUME has no defined Type Specific parameters and Parameter Len MUST
be set to 0.
When an RTP stream sender in Pausing (Section 6.2), Paused
(Section 6.3) or Local Paused State (Section 6.4) receives a valid
RESUME, and unless local considerations currently makes it impossible
to resume the stream, it SHALL enter Playing State (Section 6.1) and
act accordingly. If the RTP stream sender is incapable of honoring
the RESUME request with a valid PauseID, or receives a RESUME request
with an invalid PauseID while in Paused or Pausing state, the RTP
stream sender sends a REFUSE message as specified below.
If an RTP stream sender in Playing State receives a RESUME containing
either a valid PauseID or a PauseID that is less than the valid
PauseID, the received RESUME SHALL be ignored.
Burman, et al. Expires January 25, 2015 [Page 25]
Internet-Draft RTP Stream Pause July 2014
8.4. REFUSE
REFUSE has no defined Type Specific parameters and Parameter Len MUST
be set to 0.
If an RTP stream sender receives a valid PAUSE (Section 8.1) or
RESUME (Section 8.3) request that cannot be fulfilled by the sender
due to some local consideration, it SHALL schedule transmission of a
REFUSE indication containing the valid PauseID from the rejected
request.
If an RTP stream sender receives PAUSE or RESUME requests with a non-
valid PauseID it SHALL schedule a REFUSE response containing the
available, valid PauseID, except if the RTP stream sender is in
Playing State and receives a RESUME with a PauseID less than the
valid one, in which case the RESUME SHALL be ignored.
If several PAUSE or RESUME that would render identical REFUSE
responses are received before the scheduled REFUSE is sent, duplicate
REFUSE MUST NOT be scheduled for transmission. This effectively lets
a single REFUSE respond to several invalid PAUSE or RESUME requests.
If REFUSE containing a certain PauseID was already sent and yet more
PAUSE or RESUME messages are received that require additional REFUSE
with that specific PauseID to be scheduled, and unless the PauseID
number space has wrapped since REFUSE was last sent with that
PauseID, further REFUSE messages with that PauseID SHOULD be sent in
regular RTCP reports.
An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSE containing the same PauseID as in the request
SHOULD refrain from sending an identical request for some appropriate
time to allow the condition that caused REFUSE to clear.
An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSE containing a PauseID different from the request MAY
schedule another request using the PauseID from the REFUSE
indication.
8.5. Transmission Rules
The transmission of any RTCP feedback messages defined in this
specification MUST follow the normal AVPF defined timing rules and
depends on the session's mode of operation.
All messages defined in this specification MAY use either Regular,
Early or Immediate timings, taking the following into consideration:
Burman, et al. Expires January 25, 2015 [Page 26]
Internet-Draft RTP Stream Pause July 2014
o PAUSE SHOULD use Early or Immediate timing, except for
retransmissions that SHOULD use Regular timing.
o The first transmission of PAUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent
PAUSED for that PauseID SHOULD use Regular timing.
o RESUME SHOULD always use Immediate or Early timing.
o The first transmission of REFUSE for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent
REFUSE for that PauseID SHOULD use Regular timing.
9. Signaling
The capability of handling messages defined in this specification MAY
be exchanged at a higher layer such as SDP. This document extends
the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to
include the request for pause and resume. Like AVPF [RFC4585] and
CCM [RFC5104], it is RECOMMENDED to use the rtcp-fb attribute at
media level and it MUST NOT be used at session level. This
specification follows all the rules defined in AVPF for rtcp-fb
attribute relating to payload type in a session description.
Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
resume functionality (with the restrictions described in this
memo), signaling rtcp-fb attribute with ccm tmmbr parameter is
sufficient and no further signaling is necessary.
This specification defines two new parameters to the "ccm" feedback
value defined in CCM [RFC5104], "pause" and "paused".
o "pause" represents the capability to understand the RTCP feedback
message and all of the defined FCIs of PAUSE, RESUME, PAUSED and
REFUSE. A direction sub-parameter is used to determine if a given
node desires to issue PAUSE or RESUME requests, can respond to
PAUSE or RESUME requests, or both.
o "paused" represents the functionality of supporting the playing
and local paused states and generate PAUSED FCI when a stream
delivery is paused. A direction sub-parameter is used to
determine if a given node desires to receive these indications,
intends to send them, or both.
The reason for this separation is to make it possible for partial
implementation of this specification, according to the different
roles in the use cases section (Section 3).
Burman, et al. Expires January 25, 2015 [Page 27]
Internet-Draft RTP Stream Pause July 2014
A sub-parameter named "nowait", indicating that the hold-off time
defined in Section 6.2 can be set to 0, reducing the latency before
the stream can paused after receiving a PAUSE request. This
condition occurs when there will be only a single receiver per
direction in the RTP session, for example in point-to-point sessions.
It is also possible to use in scenarios using unidirectional media.
The conditions that allow "nowait" to be set also indicate that it
would be possible to use CCM TMMBR/TMMBN as pause/resume signaling.
A sub-parameter named "dir" is used to indicate in which directions a
given node will use the pause or paused functionality. The node
being configured or issuing an offer or an answer uses the
directionality in the following way. Note that pause and paused have
separate and different definitions.
Direction ("dir") values for "pause" is defined as follows:
sendonly: The node intends to send PAUSE and RESUME requests for
other nodes' streams and is thus also capable of receiving PAUSED
and REFUSE. It will not support receiving PAUSE and RESUME
requests.
recvonly: The node supports receiving PAUSE and RESUME requests
targeted for streams sent by the node. It will send PAUSED and
REFUSE as needed. The node will not send any PAUSE and RESUME
requests.
sendrecv: The node supports receiving PAUSE and RESUME requests
targeted for streams sent by the node. The node intends to send
PAUSE and RESUME requests for other nodes' streams. Thus the node
is capable of sending and receiving all types of pause messages.
This is the default value. If the "dir" parameter is omitted, it
MUST be interpreted to represent this value.
Direction values for "paused" is defined as follows:
sendonly: The node intends to send PAUSED indications whenever it
pauses RTP stream delivery in any of its streams. It has no need
to receive PAUSED indications itself.
recvonly: The node desires to receive PAUSED indications whenever
any stream sent by another node is paused. It does not intend to
send any PAUSED indications.
sendrecv: The nodes desires to receive PAUSED indications and
intends to send PAUSED indications whenever any stream is paused.
This is the default value. If the "dir" parameter is omitted, it
MUST be interpreted to represent this value.
Burman, et al. Expires January 25, 2015 [Page 28]
Internet-Draft RTP Stream Pause July 2014
This is the resulting ABNF [RFC5234], extending existing ABNF in
section 7.1 of CCM [RFC5104]:
rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr)
/ SP "paused" *(SP paused-attr)
pause-attr = direction
/ "nowait&it does not, then additional resources are wasted on the way down to
carry the useless RPI option.
The 6LBR will need to insert an RH3 header, which requires that it
add an IP-in-IP header. It SHOULD be able to remove the RPI, as it
was contained in an IP-in-IP header addressed to it. Otherwise,
there MAY be an RPI header buried inside the inner IP header, which
should get ignored.
Networks that use the RPL P2P extension [RFC6997] are essentially
non-storing DODAGs and fall into this scenario or scenario
Section 6.2, with the originating node acting as 6LBR.
+---------+-------------+------+--------------+-------+-------------+
| Header | 6LN src | 6LR_ | 6LBR | 6LR_i | 6LN dst |
| | | ia | | d | |
+---------+-------------+------+--------------+-------+-------------+
| Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- |
| d | IP(RPI1) | | to 6LN, opt | | |
| headers | | | RPI2) | | |
| Removed | -- | -- | IP-in- | -- | IP-in- |
| headers | | | IP(RPI1) | | IP(RH3, opt |
| | | | | | RPI2) |
| Re- | -- | -- | -- | -- | -- |
| added | | | | | |
| headers | | | | | |
| Modifie | -- | RPI1 | -- | RPI2 | -- |
| d | | | | | |
| headers | | | | | |
| Untouch | -- | -- | -- | -- | -- |
| ed | | | | | |
| headers | | | | | |
+---------+-------------+------+--------------+-------+-------------+
Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
aware-leaf
6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf
In this case the flow comprises:
6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6)
6LR_ia are the intermediate routers from source to the root In this
case, "1 <= ia >= n", n is the number of intermediate routers (6LR)
Robles, et al. Expires October 5, 2017 [Page 28]
Internet-Draft Useof6553 April 2017
6LR_id are the intermediate routers from the root to the destination.
In this case, "1 <= ia >= m", m is the number of the intermediate
routers (6LR).
As in the previous case, the 6LN will insert an RPI (RPI_1) header
which MUST be in an IP-in-IP header addressed to the root so that the
6LBR can remove this RPI. The 6LBR will then insert an RH3 inside a
new IP-in-IP header addressed to the 6LN destination node. The RPI
is optional from 6LBR to 6LR_id (RPI_2).
+--------+-----------+------------+-------------+------------+------+
| Header | 6LN | 6LR_1 | 6LBR | 6LR_id | IPv6 |
+--------+-----------+------------+-------------+------------+------+
| Insert | IP-in- | -- | IP-in- | -- | -- |
| ed hea | IP(RPI1) | | IP(RH3, opt | | |
| ders | | | RPI_2) | | |
| Remove | -- | -- | IP-in- | IP-in- | -- |
| d head | | | IP(RPI_1) | IP(RH3, | |
| ers | | | | opt RPI_2) | |
| Re- | -- | -- | -- | -- | -- |
| added | | | | | |
| header | | | | | |
| s | | | | | |
| Modifi | -- | IP-in- | -- | IP-in- | -- |
| ed hea | | IP(RPI_1) | | IP(RH3, | |
| ders | | | | opt RPI_2) | |
| Untouc | -- | -- | -- | -- | opt |
| hed he | | | | | RPI_ |
| aders | | | | | 2 |
+--------+-----------+------------+-------------+------------+------+
Non Storing: Summary of the use of headers from RPL-aware-leaf to
not-RPL-aware-leaf
6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf
In this case the flow comprises:
not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id -->
6LN
6LR_ia are the intermediate routers from source to the root In this
case, "1 <= ia >= n", n is the number of intermediate routers (6LR)
6LR_id are the intermediate routers from the root to the destination.
In this case, "1 <= ia >= m", m is the number of the intermediate
routers (6LR).
Robles, et al. Expires October 5, 2017 [Page 29]
Internet-Draft Useof6553 April 2017
This scenario is mostly identical to the previous one. The RPI is
added by the first 6LR (6LR_1) inside an IP-in-IP header addressed to
the root. The 6LBR will remove this RPI, and add it's own IP-in-IP
header containing an RH3 header and optional RPI (RPI_2).
+--------+-----+------------+-------------+------------+------------+
| Header | IPv | 6LR_1 | 6LBR | 6LR_id | 6LN |
| | 6 | | | | |
+--------+-----+------------+-------------+------------+------------+
| Insert | -- | IP-in- | IP-in- | -- | -- |
| ed hea | | IP(RPI_1) | IP(RH3, opt | | |
| ders | | | RPI_2) | | |
| Remove | -- | -- | IP-in- | -- | IP-in- |
| d head | | | IP(RPI_1) | | IP(RH3, |
| ers | | | | | opt RPI_2) |
| Re- | -- | -- | -- | -- | -- |
| added | | | | | |
| header | | | | | |
| s | | | | | |
| Modifi | -- | -- | -- | IP-in- | -- |
| ed hea | | | | IP(RH3, | |
| ders | | | | opt RPI_2) | |
| Untouc | -- | -- | -- | -- | -- |
| hed he | | | | | |
| aders | | | | | |
+--------+-----+------------+-------------+------------+------------+
Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
RPL-aware-leaf
6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-leaf
In this case the flow comprises:
not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id -->
not-RPL-aware (IPv6 dst)
6LR_ia are the intermediate routers from source to the root In this
case, "1 <= ia >= n", n is the number of intermediate routers (6LR)
6LR_id are the intermediate routers from the root to the destination.
In this case, "1 <= ia >= m", m is the number of the intermediate
routers (6LR).
This scenario is the combination of the previous two cases.
Robles, et al. Expires October 5, 2017 [Page 30]
Internet-Draft Useof6553 April 2017
+---------+-----+--------------+---------------+-------------+------+
| Header | IPv | 6LR_1 | 6LBR | 6LR_id | IPv6 |
| | 6 | | | | dst |
| | src | | | | |
+---------+-----+--------------+---------------+-------------+------+
| Inserte | -- | IP-in- | IP-in-IP(RH3) | -- | -- |
| d | | IP(RPI_1) | | | |
| headers | | | | | |
| Removed | -- | -- | IP-in- | IP-in- | -- |
| headers | | | IP(RPI_1) | IP(RH3, opt | |
| | | | | RPI_2) | |
| Re- | -- | -- | -- | -- | -- |
| added | | | | | |
| headers | | | | | |
| Modifie | -- | -- | -- | -- | -- |
| d | | | | | |
| headers | | | | | |
| Untouch | -- | -- | -- | -- | -- |
| ed | | | | | |
| headers | | | | | |
+---------+-----+--------------+---------------+-------------+------+
Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
not-RPL-aware-leaf
7. Observations about the cases
7.1. Storing mode
[I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP
header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header
as described in Section 7 of the document.
There are potential significant advantages to having a single code
path that always processes IP-in-IP headers with no options.
Thanks to the relaxation of the RFC2460 rule about discarding unknown
Hop-by-Hop options, there is no longer any uncertainty about when to
use an IPIP header in the storing mode case. The RPI header SHOULD
always be added when 6LRs originate packets (without IPIP headers),
and IPIP headers should always be added (addressed to the root when
on the way up, to the end-host when on the way down) when a 6LR finds
it needs to insert an RPI header.
In order to support the above two cases with full generality, the
different situations (always do IP-in-IP vs never use IP-in-IP)
should be signaled in the RPL protocol itself.
Robles, et al. Expires October 5, 2017 [Page 31]
Internet-Draft Useof6553 April 2017
7.2. Non-Storing mode
In the non-storing case, dealing with non-RPL aware leaf nodes is
much easier as the 6LBR (DODAG root) has complete knowledge about the
connectivity of all DODAG nodes, and all traffic flows through the
root node.
The 6LBR can recognize non-RPL aware leaf nodes because it will
receive a DAO about that node from the 6LN immediately above that
node. This means that the non-storing mode case can avoid ever using
hop-by-hop IP-in-IP headers.
Unlike in the storing mode case, there is no need for all nodes to
know about the existence of non-RPL aware nodes. Only the 6LBR needs
to change when there are non-RPL aware nodes. Further, in the non-
storing case, the 6LBR is informed by the DAOs when there are non-RPL
aware nodes.
8. 6LoRH Compression cases
The [I-D.ietf-roll-routing-dispatch] proposes a compression method
for RPI, RH3 and IPv6-in-IPv6.
In Storing Mode, for the examples of Flow from RPL-aware-leaf to non-
RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
an IP-in-IP and RPI compression headers. The type of this case is
critical since IP-in-IP is encapsulating a RPI header.
+--+-----+---+--------------+-----------+-------------+-------------+
|1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC |
+--+-----+---+--------------+-----------+-------------+-------------+
Figure 3: Critical IP-in-IP (RPI).
9. IANA Considerations
There are no IANA considerations related to this document.
10. Security Considerations
The security considerations covering of [RFC6553] and [RFC6554] apply
when the packets get into RPL Domain.
The IPIP mechanism described in this document is much more limited
than the general mechanism described in [RFC2473]. The willingness
Robles, et al. Expires October 5, 2017 [Page 32]
Internet-Draft Useof6553 April 2017
quot;
/ token ; for future extensions
paused-attr = direction
/ token ; for future extensions
direction = "dir=" direction-alts
direction-alts = "sendonly" / "recvonly" / "sendrecv"
Figure 6: ABNF
An endpoint implementing this specification and using SDP to signal
capability SHOULD indicate both of the new "pause" and "paused"
parameters with ccm signaling. When negotiating usage, it is
possible select either of them, noting that "pause" contain the full
"paused" functionality. A sender or receiver SHOULD NOT use the
messages from this specification towards receivers that did not
declare capability for it.
There MUST NOT be more than one "a=rtcp-fb" line with "pause" and one
with "paused" applicable to a single payload type in the SDP, unless
the additional line uses "*" as payload type, in which case "*" SHALL
be interpreted as applicable to all listed payload types that does
not have an explicit "pause" or "paused" specification.
There MUST NOT be more than a single direction sub-parameter per
"pause" and "paused" parameter. There MUST NOT be more than a single
"nowait" sub-parameter per "pause" parameter.
9.1. Offer-Answer Use
An offerer implementing this specification needs to include "pause"
and/or "paused" CCM parameters with suitable directionality parameter
("dir") in the SDP, according to what messages it intends to send and
desires or is capable to receive in the session. It is RECOMMENDED
to include both "pause" and "paused" if "pause" is supported, to
enable at least the "paused" functionality if the answer only
supports "paused" or different directionality for the two
functionalities. The "pause" and "paused" functionalities are
negotiated independently, although the "paused" functionality is part
of the "pause" functionality. As a result, an answerer MAY remove
"pause" or "paused" lines from the SDP depending on the agreed mode
of functionality.
Burman, et al. Expires January 25, 2015 [Page 29]
Internet-Draft RTP Stream Pause July 2014
In offer/answer, the "dir" parameter is interpreted based on the
agent providing the SDP. The node described in the offer is the
offerer, and the answerer is described in an answer. In other words,
an offer for "paused dir=sendonly" means that the offerer intends to
send PAUSED indications whenever it pauses RTP stream delivery in any
of its streams.
An answerer receiving an offer with a "pause" parameter with
dir=sendrecv MAY remove the pause line in its answer, respond with
pause keeping sendrecv for full bi-directionality, or it may change
dir value to either sendonly or recvonly based on its capabilities
and desired functionality. An offer with a "pause" parameter with
dir=sendonly or dir=recvonly is either completely removed or accepted
with reverse directionality, i.e. sendonly becomes recvonly or
recvonly becomes sendonly.
An answer receiving an offer with "paused" has the same choices as
for "pause" above. It should be noted that the directionality of
pause is the inverse of RTP stream direction, while the
directionality of paused is the same as the RTP stream direction.
If the offerer believes that itself and the intended answerer are
likely the only End Points in the RTP session, it MAY include the
"nowait" sub-parameter on the "pause" line in the offer. If an
answerer receives the "nowait" sub-parameter on the "pause" line in
the SDP, and if it has information that the offerer and itself are
not the only End Points in the RTP session, it MUST NOT include any
"nowait" sub-parameter on its "pause" line in the SDP answer. The
answerer MUST NOT add "nowait" on the "pause" line in the answer
unless it is present on the "paused" line in the offer. If both
offer and answer contained a "nowait" parameter, then the hold-off
time is configured to 0 at both offerer and answerer.
9.2. Declarative Use
In declarative use, the SDP is used to configure the node receiving
the SDP. This has implications on the interpretation of the SDP
signaling extensions defined in this draft. First, it is normally
only necessary to include either "pause" or "paused" parameter to
indicate the level of functionality the node should use in this RTP
session. Including both is only necessary if some implementations
only understands "paused" and some other can understand both. Thus
indicating both means use pause if you understand it, and if you only
understand paused, use that.
The "dir" directionality parameter indicates how the configured node
should behave. For example "pause" with sendonly:
Burman, et al. Expires January 25, 2015 [Page 30]
Internet-Draft RTP Stream Pause July 2014
sendonly: The node intends to send PAUSE and RESUME requests for
other nodes' streams and is thus also capable of receiving PAUSED
and REFUSE. It will not support receiving PAUSE and RESUME
requests.
In this example, the configured node should send PAUSE and RESUME
requests if has reason for it. It does not need to respond to any
PAUSE or RESUME requests as that is not supported.
The "nowait" parameter, if included, is followed as specified. It is
the responsibility of the declarative SDP sender to determine if a
configured node will participate in a session that will be point to
point, based on the usage. For example, a conference client being
configured for an any source multicast session using SAP [RFC2974]
will not be in a point to point session, thus "nowait" cannot be
included. An RTSP [RFC2326] client receiving a declarative SDP may
very well be in a point to point session, although it is highly
doubtful that an RTSP client would need to support this
specification, considering the inherent PAUSE support in RTSP.
10. Examples
The following examples shows use of PAUSE and RESUME messages,
including use of offer-answer:
1. Offer-Answer
2. Point-to-Point session
3. Point-to-Multipoint using Mixer
4. Point-to-Multipoint using Translator
10.1. Offer-Answer
The below figures contains an example how to show support for pausing
and resuming the streams, as well as indicating whether or not the
hold-off period can be set to 0.
Burman, et al. Expires January 25, 2015 [Page 31]
Internet-Draft RTP Stream Pause July 2014
v=0
o=alice 3203093520 3203093520 IN IP4 alice.example.com
s=Pausing Media
t=0 0
c=IN IP4 alice.example.com
m=audio 49170 RTP/AVPF 98 99
a=rtpmap:98 G719/48000
a=rtpmap:99 PCMA/8000
a=rtcp-fb:* ccm pause nowait
a=rtcp-fb:* ccm paused
Figure 7: SDP Offer With Pause and Resume Capability
The offerer supports all of the messages defined in this
specification and offers a sendrecv stream. The offerer also
believes that it will be the sole receiver of the answerer's stream
as well as that the answerer will be the sole receiver of the
offerer's stream and thus includes the "nowait" sub-parameter for
both "pause" and "paused" parameters.
This is the SDP answer:
v=0
o=bob 293847192 293847192 IN IP4 bob.example.com
s=-
t=0 0
c=IN IP4 bob.example.com
m=audio 49202 RTP/AVPF 98
a=rtpmap:98 G719/48000
a=rtcp-fb:98 ccm pause dir=sendonly
a=rtcp-fb:98 ccm paused
Figure 8: SDP Answer With Pause and Resume Capability
The answerer will not allow its sent streams to be paused or resumed
and thus support pause only in sendonly mode. It does support paused
and intends to send it, and also desires to receive PAUSED
indications. Thus paused in sendrecv mode is included in the answer.
The answerer somehow knows that it will not be a point-to-point RTP
session and has therefore removed "nowait" from the "pause" line,
meaning that the offerer must use a non-zero hold-off time when being
requested to pause the stream.
When using TMMBR 0 / TMMBN 0 to achieve pause and resume
functionality, there are no differences in SDP compared to CCM
[RFC5104] and therefore no such examples are included here.
Burman, et al. Expires January 25, 2015 [Page 32]
Internet-Draft RTP Stream Pause July 2014
10.2. Point-to-Point Session
This is the most basic scenario, which involves two participants,
each acting as a sender and/or receiver. Any RTP data receiver sends
PAUSE or RESUME messages to the sender, which pauses or resumes
transmission accordingly. The hold-off time before pausing a stream
is 0.
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| -------------------------------of each node in the LLN to decapsulate traffic and forward it could
be exploited by nodes to disguise the origin of an attack.
Nodes outside of the LLN will need to pass IPIP traffic through the
RPL root in order to perform this attack. To counter the RPL root
SHOULD either restrict ingress of IPIP packets (the simpler
solution), or it SHOULD do a deep packet inspection wherein it walks
the IP header extension chain until it can inspect the upper-layer-
payload as described in [RFC7045]. In particular, the RPL root
SHOULD do BCP38 ([RFC2827]) processing on the source addresses of all
IP headers that it examines in both directions.
Note: there are some situations where a prefix will spread across
multiple LLNs via mechanisms such as [I-D.ietf-6lo-backbone-router].
In this case the BCP38 filtering needs to take this into account.
Nodes with the LLN are able to use the IPIP mechanism to mount an
attack on another part of the LLN, while disguising the origin of the
attack. The mechanism can even be abused to make it appear that the
attack is coming from outside the LLN, and unless countered, this
could be used to mount a Distributed Denial of Service attack upon
nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of
such attacks already seen in the real world.
While a typical LLN may be a very poor origin for attack traffic, as
the networks tend to very slow, and the nodes often have very low
duty cycles, given enough of them, they could still have a
significant impact, particularly if the attack was on another LLN!
Additionally, some uses of RPL involve large backbone ISP scale
equipment [I-D.ietf-anima-autonomic-control-plane], which may be
equipped with multiple 100Gb/s interfaces.
Blocking or careful filtering of IPIP traffic entering the LLN as
described above will make sure that any attack that is mounted must
be originated from compromised nodes within the LLN. The use of
BCP38 filtering at the RPL root on egress traffic will both alert the
operator to the existence of the attack, as well as drop the attack
traffic. As the RPL network is typically numbered from a single
prefix, which is itself assigned by RPL, BCP38 filtering involves a
single prefix comparison and should be trivial to automatically
configure.
There are some scenarios where IPIP traffic SHOULD be allowed to pass
through the RPL root, such as the IPIP mediated communications
between a new Pledge and the Join Coordinator when using
[I-D.ietf-anima-bootstrapping-keyinfra] and
[I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the
Robles, et al. Expires October 5, 2017 [Page 33]
Internet-Draft Useof6553 April 2017
RPL root to do careful filtering: it occurs only when the Join
Coordinator is not co-located inside the RPL root.
With the above precautions, an attack using IPIP tunnels will be by a
node within the LLN on another node within the LLN. Such an attack
could, of course, be done directly. An attack of this kind is
meaningful only if the source addresses are either fake or if the
point is for (amplified) return traffic to be the attack. Such an
attack, could also be done without the use of IPIP headers using
forged source addresses. If the attack requires bi-directional
communication, then IPIP provides no advantages.
[RFC2473] suggests that tunnel entry and exit points can be secured,
via the "Use IPsec". This solution has all the problems that
[RFC5406] goes into. In an LLN such a solution would degenerate into
every node having a tunnel with every other node. It would provide a
small amount of origin address authentication at a very high cost;
doing BCP38 at every node (linking layer-3 addresses to layer-2
addresses, and to already present layer-2 cryptographic mechanisms)
would be cheaper should RPL be run in an environment where hostile
nodes are likely to be a part of the LLN.
The RH3 header usage described here can be abused in equivalent ways
to the IPIP header. In non-storing networks where an RH3 may be
acted upon, packets arriving into the LLN will be encapsulated with
an IPIP header in order to add the needed RH3 header. As such, the
attacker's RH3 header will not be seen by the network until it
reaches the end host, which will decapsulate it. An end-host SHOULD
be suspicious about a RH3 header which has additional hops which have
not yet been processed, and SHOULD ignore such a second RH3 header.
In addition, the LLN will likely use [I-D.ietf-roll-routing-dispatch]
to compress the IPIP and RH3 headers. As such, the compressor at the
RPL-root will see the second RH3 header and MAY choose to discard the
packet if the RH3 header has not been completely consumed. A
consumed (inert) RH3 header could be present in a packet that flows
from one LLN, crosses the Internet, and enters another LLN. As per
the discussion in this document, such headers do not need to be
removed. However, there is no case described in this document where
an RH3 is inserted in a non-storing network on traffic that is
leaving the LLN, but this document SHOULD NOT preclude such a future
innovation. It should just be noted that an incoming RH3 must be
fully consumed, or very carefully inspected.
The RPI header, if permitted to enter the LLN, could be used by an
attacker to change the priority of a packet by selecting a different
RPL instanceID, perhaps one with a higher energy cost, for instance.
It could also be that not all nodes are reachable in an LLN using the
Robles, et al. Expires October 5, 2017 [Page 34]
Internet-Draft Useof6553 April 2017
default instanceID, but a change of instanceID would permit an
attacker to bypass such filtering. Like the RH3, an RPI header is to
be inserted by the RPL root on traffic entering the LLN by first
inserting an IPIP header. The attacker's RPI header therefore will
not be seen by the network. Upon reaching the destination node the
RPI header has no further meaning and is just skipped; the presence
of a second RPI header will have no meaning to the end node as the
packet has already been identified as being at it's final
destination.
The RH3 and RPI headers could be abused by an attacker inside of the
network to route packets on non-obvious ways, perhaps eluding
observation. This usage is in fact part of [RFC6997] and can not be
restricted at all. This is a feature, not a bug.
[RFC7416] deals with many other threats to LLNs not directly related
to the use of IPIP headers, and this document does not change that
analysis.
11. Acknowledgments
This work is partially funded by the FP7 Marie Curie Initial Training
Network (ITN) METRICS project (grant agreement No. 607728).
The authors would like to acknowledge the review, feedback, and
comments of (alphabetical order): Robert Cragie, Simon Duquennoy,
Cenk Guendogan, Rahul Jadhav, Peter van der Stok, Xavier Vilajosana
and Thomas Watteyne.
12. References
12.1. Normative References
[I-D.ietf-6man-rfc2460bis]
<>, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", draft-ietf-6man-rfc2460bis-09 (work in
progress), March 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Robles, et al. Expires October 5, 2017 [Page 35]
Internet-Draft Useof6553 April 2017
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
Version 2", BCP 146, RFC 5406, February 2009.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012,
<http://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<http://www.rfc-editor.org/info/rfc6554>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<http://www.rfc-editor.org/info/rfc7416>.
12.2. Informative References
[DDOS-KREBS]
Goodin, D., "Record-breaking DDoS reportedly delivered by
>145k hacked cameras", September 2016,
<http://arstechnica.com/security/2016/09/botnet-of-145k-
cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
Robles, et al. Expires October 5, 2017 [Page 36]
Internet-Draft Useof6553 April 2017
[I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-03 (work in progress), January 2017.
[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work
in progress), January 2017.
[I-D.ietf-6tisch-dtsecurity-secure-join]
Richardson, M., "6tisch Secure Join protocol", draft-ietf-
6tisch-dtsecurity-secure-join-01 (work in progress),
February 2017.
[I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane", draft-ietf-anima-autonomic-control-
plane-06 (work in progress), March 2017.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-05 (work in progress), March 2017.
[I-D.ietf-roll-dao-projection]
Thubert, P. and J. Pylakutty, "Root initiated routing
state in RPL", draft-ietf-roll-dao-projection-01 (work in
progress), March 2017.
[I-D.ietf-roll-routing-dispatch]
Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
"6LoWPAN Routing Header", draft-ietf-roll-routing-
dispatch-05 (work in progress), October 2016.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
Robles, et al. Expires October 5, 2017 [Page 37]
Internet-Draft Useof6553 April 2017
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013,
<http://www.rfc-editor.org/info/rfc6997>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>.
[Second6TischPlugtest]
"2nd 6Tisch Plugtest", <http://www.ietf.org/mail-
archive/web/6tisch/current/pdfgDMQcdCkRz.pdf>.
> |
| t2: PAUSE(3) |
| <------------------------------- |
| < RTP data paused > |
| t3: PAUSED(3) |
| -------------------------------> |
: < Some time passes > :
| t4: RESUME(3) |
| <------------------------------- |
| t5: RTP data |
| -------------------------------> |
: < Some time passes > :
| t6: PAUSE(4) |
| <------------------------------- |
| < RTP data paused > |
: :
Figure 9: Pause and Resume Operation in Point-to-Point
Figure 9 shows the basic pause and resume operation in Point-to-Point
scenario. At time t1, an RTP sender sends data to a receiver. At
time t2, the RTP receiver requests the sender to pause the stream,
using PauseID 3 (which it knew since before in this example). The
sender pauses the data and replies with a PAUSED containing the same
PauseID. Some time later (at time t4) the receiver requests the
sender to resume, which resumes its transmission. The next PAUSE,
sent at time t6, contains an updated PauseID (4).
Burman, et al. Expires January 25, 2015 [Page 33]
Internet-Draft RTP Stream Pause July 2014
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| -------------------------------> |
| t2: TMMBR 0 |
| <------------------------------- |
| < RTP data paused > |
| t3: TMMBN 0 |
| -------------------------------> |
: < Some time passes > :
| t4: TMMBR 150000 |
| <------------------------------- |
| t5: RTP data |
| -------------------------------> |
: < Some time passes > :
| t6: TMMBR 0 |
| <------------------------------- |
| < RTP data paused > |
: :
Figure 10: TMMBR Pause and Resume in Point-to-Point
Figure 10 describes the same point-to-point scenario as above, but
using TMMBR/TMMBN signaling.
Burman, et al. Expires January 25, 2015 [Page 34]
Internet-Draft RTP Stream Pause July 2014
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| ------------------------------------> |
| t2: PAUSE(7), lost |
| <---X-------------- |
| |
| t3: RTP data |
| ------------------------------------> |
: :
| <Timeout, still receiving data> |
| t4: PAUSE(7) |
| <------------------------------------ |
| < RTP data paused > |
| t5: PAUSED(7) |
| ------------------------------------> |
: < Some time passes > :
| t6: RESUME(7), lost |
| <---X-------------- |
| t7: RESUME(7) |
| <------------------------------------ |
| t8: RTP data |
| ------------------------------------> |
| t9: RESUME(7) |
| <------------------------------------ |
: :
Figure 11: Pause and Resume Operation With Messages Lost
Figure 11 describes what happens if a PAUSE message from an RTP
stream receiver does not reach the RTP stream sender. After sending
a PAUSE message, the RTP stream receiver waits for a time-out to
detect if the RTP stream sender has paused the data transmission or
has sent PAUSED indication according to the rules discussed in
Section 6.3. As the PAUSE message is lost on the way (at time t2),
RTP data continues to reach to the RTP stream receiver. When the
timer expires, the RTP stream receiver schedules a retransmission of
the PAUSE message, which is sent at time t4. If the PAUSE message
now reaches the RTP stream sender, it pauses the RTP stream and
replies with PAUSED.
At time t6, the RTP stream receiver wishes to resume the stream again
and sends a RESUME, which is lost. This does not cause any severe
effect, since there is no requirement to wait until further RESUME
are sent and another RESUME are sent already at time t7, which now
reaches the RTP stream sender that consequently resumes the stream at
Burman, et al. Expires January 25, 2015 [Page 35]
Internet-Draft RTP Stream Pause July 2014
time t8. The time interval between t6 and t7 can vary, but may for
example be one RTCP feedback transmission interval as determined by
the AVPF rules.
The RTP stream receiver did not realize that the RTP stream was
resumed in time to stop yet another scheduled RESUME from being sent
at time t9. This is however harmless since the RESUME PauseID is
less than the valid one and will be ignored by the RTP stream sender.
It will also not cause any unwanted resume even if the stream was
paused based on a PAUSE from some other receiver before receiving the
RESUME, since the valid PauseID is now larger than the one in the
stray RESUME and will only cause a REFUSE containing the new valid
PauseID from the RTP stream sender.
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| ------------------------------> |
| t2: PAUSE(11) |
| <------------------------------ |
| |
| < Can not pause RTP data > |
| t3: REFUSE(11) |
| ------------------------------> |
| |
| t4: RTP data |
| ------------------------------> |
: :
Figure 12: Pause Request is Refused in Point-to-Point
In Figure 12, the receiver requests to pause the sender, which
refuses to pause due to some consideration local to the sender and
responds with a REFUSE message.
10.3. Point-to-Multipoint using Mixer
An RTP Mixer is an intermediate node connecting different transport-
level clouds. The Mixer receives streams from different RTP sources,
selects or combines them based on the application's needs and
forwards the generated stream(s) to the destination. The Mixer
typically puts its' own SSRC(s) in RTP data packets instead of the
original source(s).
The Mixer keeps track of all the streams delivered to the Mixer and
how they are currently used. In this example, it selects the video
Burman, et al. Expires January 25, 2015 [Page 36]
Internet-Draft RTP Stream Pause July 2014
stream to deliver to the receiver R based on the voice activity of
the RTP stream senders. The video stream will be delivered to R
using M's SSRC and with an CSRC indicating the original source.
Note that PauseID is not of any significance for the example and is
therefore omitted in the description.
+-----+ +-----+ +-----+ +-----+
| R | | M | | S1 | | S2 |
+-----+ +-----| +-----+ +-----+
: : t1:RTP(S1) : :
| t2:RTP(M:S1) |<-----------------| |
|<-----------------| | |
| | t3:RTP(S2) | |
| |<------------------------------------|
| | t4: PAUSE(S2) | |
| |------------------------------------>|
| | | t5: PAUSED(S2) |
| |<------------------------------------|
| | | <S2:No RTP to M> |
| | t6: RESUME(S2) | |
| |------------------------------------>|
| | | t7: RTP to M |
| |<------------------------------------|
| t8:RTP(M:S2) | | |
|&Authors' Addresses
Maria Ines Robles
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: maria.ines.robles@ericsson.com
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/mcr/
Pascal Thubert
Cisco Systems, Inc
Village d'Entreprises Green Side 400, Avenue de Roumanille
Batiment T3, Biot - Sophia Antipolis 06410
France
Email: pthubert@cisco.com
Robles, et al. Expires October 5, 2017 [Page 38]