A Mixer Control Package for the Media Control Channel Framework
draft-ietf-mediactrl-mixer-control-package-14
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6505.
|
|
|---|---|---|---|
| Authors | Scott McGlashan , Tim J. Melanchuk , Chris Boulton | ||
| Last updated | 2015-10-14 (Latest revision 2011-01-06) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6505 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Robert Sparks | ||
| IESG note | ** No value found for 'doc.notedoc.note' ** | ||
| Send notices to | (None) |
draft-ietf-mediactrl-mixer-control-package-14
Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones
Updates: 4821, 4960, 6951, 8085, 8261 (if University of Aberdeen
approved) M. Tuexen
Intended status: Standards Track I. Ruengeler
Expires: 24 September 2020 T. Voelker
Muenster University of Applied Sciences
23 March 2020
Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-17
Abstract
This document describes a robust method for Path MTU Discovery
(PMTUD) for datagram Packetization Layers (PLs). It describes an
extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path
MTU Discovery for IPv4 and IPv6. The method allows a PL, or a
datagram application that uses a PL, to discover whether a network
path can support the current size of datagram. This can be used to
detect and reduce the message size when a sender encounters a packet
black hole (where packets are discarded). The method can probe a
network path with progressively larger packets to discover whether
the maximum packet size can be increased. This allows a sender to
determine an appropriate packet size, providing functionality for
datagram transports that is equivalent to the Packetization Layer
PMTUD specification for TCP, specified in RFC 4821.
The document updates RFC 4821 to specify the method for datagram PLs,
and updates RFC 8085 as the method to use in place of RFC 4821 with
UDP datagrams. Section 7.3 of RFC4960 recommends an endpoint apply
the techniques in RFC 4821 on a per-destination-address basis. RFC
4960, RFC 6951 and RFC 8261 are updated to recommend that SCTP, SCTP
encapsulated in UDP and SCTP encapsulated in DTLS use the method
specified in this document instead of the method in RFC 4821.
The document also provides implementation notes for incorporating
Datagram PMTUD into IETF datagram transports or applications that use
datagram transports.
When published, this specification updates RFC 4960, RFC 4821, RFC
8085 and RFC 8261.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Fairhurst, et al. Expires 24 September 2020 [Page 1]
Internet-Draft DPLPMTUD March 2020
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 https://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 24 September 2020.
Copyright Notice
Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4
1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6
1.3. Path MTU Discovery for Datagram Services . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 10
4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 13
4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 13
4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 14
4.3. Black Hole Detection . . . . . . . . . . . . . . . . . . 15
4.4. The Maximum Packet Size (MPS) . . . . . . . . . . . . . . 16
4.5. Disabling the Effect of PMTUD . . . . . . . . . . . . . . 17
4.6. Response to PTB Messages . . . . . . . . . . . . . . . . 17
4.6.1. Validation of PTB Messages . . . . . . . . . . . . . 17
4.6.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 18
5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 20
5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 20
5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 21
5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 22
Fairhurst, et al. Expires 24 September 2020 [Page 2]
Internet-Draft DPLPMTUD March 2020
5.1.4. Overview of DPLPMTUD Phases . . . . . . . . . . . . . 23
5.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 25
5.3. Search to Increase the PLPMTU . . . . . . . . . . . . . . 28
5.3.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 28
5.3.2. Selection of Probe Sizes . . . . . . . . . . . . . . 29
5.3.3. Resilience to Inconsistent Path Information . . . . . 29
5.4. Robustness to Inconsistent Paths . . . . . . . . . . . . 30
6. Specification of Protocol-Specific Methods . . . . . . . . . 30
6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 30
6.1.1. Application Request . . . . . . . . . . . . . . . . . 31
6.1.2. Application Response . . . . . . . . . . . . . . . . 31
6.1.3. Sending Application Probe Packets . . . . . . . . . . 31
6.1.4. Initial Connectivity . . . . . . . . . . . . . . . . 31
6.1.5. Validating the Path . . . . . . . . . . . . . . . . . 31
6.1.6. Handling of PTB Messages . . . . . . . . . . . . . . 31
6.2. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 32
6.2.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32
6.2.1.1. Initial Connectivity . . . . . . . . . . . . . . 32
6.2.1.2. Sending SCTP Probe Packets . . . . . . . . . . . 32
6.2.1.3. Validating the Path with SCTP . . . . . . . . . . 33
6.2.1.4. PTB Message Handling by SCTP . . . . . . . . . . 33
6.2.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 33
6.2.2.1. Initial Connectivity . . . . . . . . . . . . . . 33
6.2.2.2. Sending SCTP/UDP Probe Packets . . . . . . . . . 34
6.2.2.3. Validating the Path with SCTP/UDP . . . . . . . . 34
6.2.2.4. Handling of PTB Messages by SCTP/UDP . . . . . . 34
6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 34
6.2.3.1. Initial Connectivity . . . . . . . . . . . . . . 34
6.2.3.2. Sending SCTP/DTLS Probe Packets . . . . . . . . . 34
6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 34
6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 35
6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 35
6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 35
6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 35
6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 36
6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 36
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
Fairhurst, et al. Expires 24 September 2020 [Page 3]
Internet-Draft DPLPMTUD March 2020
>
</event>
</mscmixer>
6.2.2. Bridging connections
The mixer package can be used to join connections to one another. In
a call center scenario, for example, this package can be used to set
up and modify connections between a caller, agent and supervisor.
A caller is joined to an agent with bi-directional audio:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="caller:001" id2="agent:002">
<stream media="audio" direction="sendrecv"/>
</join>
</mscmixer>
If the MS is able to establish this connection, then it would send a
200 response:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<response status="200"/>
</mscmixer>
Now assume that the AS wants a supervisor to listen into the agent
McGlashan, et al. Expires July 10, 2011 [Page 82]
Internet-Draft Mixer Control Package January 2011
conversation with the caller and provide whispered guidance to the
agent. First the AS would send a request to join the supervisor and
the caller connections:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="supervisor:003" id2="caller:001">
<stream media="audio" direction="recvonly"/>
</join>
</mscmixer>
If this request was successful, audio output from the caller
connection would now be sent to both the agent and the supervisor.
Second, the AS would send a request to join the supervisor and the
agent connections:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<join id1="supervisor:001" id2="agent:002">
<stream media="audio" direction="sendrecv"/>
</join>
</mscmixer>
If this request was successful, the audio mixing would occur on both
the agent and supervisor connections: the agent would hear the caller
and supervisor, and the supervisor would hear the agent and caller.
The caller would only hear the agent. If the MS is unable to join
and mix connections in this way, it would send a 426 response.
6.2.3. Video conferencing
In this example, an audio video-conference is created with the
loudest participant has the most prominent region in the video
layout.
The AS sends a request to create an audio-video conference:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<createconference conferenceid="conf2">
<audio-mixing type="nbest"/>
<video-layouts>
<video-layout min-participants="1"><single-view/></video-layout>
<video-layout min-participants="2"><dual-view/></video-layout>
<video-layout min-participants="3"><quad-view/></video-layout>
<video-layout min-participants="5"><multiple-5x1/></video-layout>
</video-layouts>
<video-switch><vas/></video-switch>
</createconference>
</mscmixer>
McGlashan, et al. Expires July 10, 2011 [Page 83]
Internet-Draft Mixer Control Package January 2011
In this configuration, the conference uses a nbest audio mixing
policy and a <vas/> video switch policy, so that the loudest speaker
receives the most prominent region in the layout. Multiple video
layouts are specified and active one depends on the number of
participants.
Assume that 4 participants are already joined to the conference. In
that case, the video layout will be quad-view (Figure 6) with the
most active speaker displayed in region 1. When a fifth participant
joins, the video layout automatically switches to a multiple-5x1
layout (Figure 9), again with the most active speaker in region 1.
The AS can manipulate which participants are displayed in the
remaining regions. For example, it could force an existing
conference participant to be displayed in region 2:
<mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">
<modifyjoin id1="1536067209:913cd14c" id2="conf2">
<stream media="video">
<region>2</region>
</stream>
</modifyjoin>
</mscmixer>
McGlashan, et al. Expires July 10, 2011 [Page 84]
Internet-Draft Mixer Control Package January 2011
7. Security Considerations
As this control package processes XML markup, implementations MUST
address the security considerations of [RFC3023].
As a Control Package of the Media Control Channel Framework,
security, confidentiality and integrity of messages transported over
the control channel MUST be addressed as described in Section 12 of
the Media Control channel Framework
([I-D.ietf-mediactrl-sip-control-framework]), including Transport
Level Protection, Control Channel Policy Management and Session
Establishment. In addition, implementations MUST address security,
confidentiality and integrity of User Agent sessions with the MS,
both in terms of SIP signaling and associated RTP media flow; see
[I-D.ietf-mediactrl-sip-control-framework] for further details on
this topic.
Adequate transport protection and authentication are critical,
especially when the implementation is deployed in open networks. If
the implementation fails to correctly address these issues, it risks
exposure to malicious attacks, including (but not limited to):
Denial of Service: An attacker could insert a request message into
the transport stream causing specific conferences or join mixers
on the MS to be destroyed. For example, <destroyconference
conferenceid="XXXX">, where the value of "XXXX" could be guessed
or discovered by auditing active mixers on the MS using an <audit>
request. Likewise, an attacker could impersonate the MS and
insert error responses into the transport stream so denying the AS
access to package capabilities.
Resource Exhaustion: An attacker could insert into the control
channel new request messages (or modify existing ones) with, for
instance, <createconference> elements causing large numbers of
conference mixer resources to be allocated. At some point this
will exhaust the number of conference mixers that the MS is able
to allocate.
The Media Control Channel Framework permits additional policy
management, including resource access and control channel usage, to
be specified at the control package level beyond that specified for
the Media Control Channel Framework (see Section 12.3 of
[I-D.ietf-mediactrl-sip-control-framework]).
Since creation of conference and join mixers is associated with media
mixing resources on the MS, the security policy for this control
package needs to address how such mixers are securely managed across
more than one control channel. Such a security policy is only useful
McGlashan, et al. Expires July 10, 2011 [Page 85]
Internet-Draft Mixer Control Package January 2011
for secure, confidential and integrity protected channels. The
identity of control channels is determined by the channel identifier:
i.e. the value of the cfw-id attribute in the SDP and Dialog-ID
header in the channel protocol (see
[I-D.ietf-mediactrl-sip-control-framework]). Channels are the same
if they have the same identifier; otherwise, they are different.
This control package imposes the following additional security
policies:
Responses: The MS MUST only send a response to a mixer management or
audit request using the same control channel as the one used to
send the request.
Notifications: The MS MUST only send notification events for
conference and join mixers using the same control channel as it
received the request creating the mixer.
Auditing: The MS MUST only provide audit information about
conference and join mixers which have been created on the same
control channel as the one upon the <audit> request is sent. For
example, if a join between two connections has been created on one
channel, then a request on another channel to audit all mixers -
<audit mixers="true"/> - would not report on this join mixer.
Rejection: The MS SHOULD reject requests to audit or manipulate an
existing conference or join mixer on the MS if the channel is not
the same as the one used when the mixer was created. The MS
rejects a request by sending a Control Framework 403 response (see
Section 7.4 and Section 12.3 of
[I-D.ietf-mediactrl-sip-control-framework]). For example, if a
channel with identifier 'cfw1234' has been used to send a request
to create a particular conference and the MS receives on channel
'cfw98969' a request to audit or destroy this particular
conference, then the MS sends a 403 framework response.
There can be valid reasons why an implementation does not reject an
audit or mixer manipulation request on a different channel from the
one which created the mixer. For example, a system administrator
might require a separate channel to audit mixer resources created by
system users and to terminate mixers consuming excessive system
resources. Alternatively, a system monitor or resource broker might
require a separate channel to audit mixers managed by this package on
a MS. However, the full implications need to be understood by the
implementation and carefully weighted before accepting these reasons
as valid. If the reasons are not valid in their particular
circumstances, the MS rejects such requests.
There can also be valid reasons for 'channel handover' including high
McGlashan, et al. Expires July 10, 2011 [Page 86]
Internet-Draft Mixer Control Package January 2011
availability support or where one AS needs to take over management of
mixers after the AS which created them has failed. This could be
achieved by the control channels using the same channel identifier,
one after another. For example, assume a channel is created with the
identifier 'cfw1234' and the channel is used to create mixers on the
MS. This channel (and associated SIP dialog) then terminates due to
a failure on the AS. As permitted by the Control Framework, the
channel identifier 'cfw1234' could then be reused so that another
channel is created with the same identifier 'cfw1234', allowing it to
'take over' management of the mixers on the MS. Again, the
implementation needs to understand the full implications and
carefully weight them before accepting these reasons as valid. If
the reasons are not valid for their particular circumstances, the MS
uses the appropriate SIP mechanisms to prevent session establishment
when the same channel identifier is used in setting up another
control channel (see Section 4 of
[I-D.ietf-mediactrl-sip-control-framework]).
McGlashan, et al. Expires July 10, 2011 [Page 87]
Internet-Draft Mixer Control Package January 2011
8. IANA Considerations
This specification instructs IANA to register a new Media Control
Channel Framework Package, a new XML namespace, a new XML schema and
a new MIME type.
8.1. Control Package Registration
This section registers a new Media Control Channel Framework package,
per the instructions in Section 12.1 of
[I-D.ietf-mediactrl-sip-control-framework].
To: ietf-sip-control@iana.org
Subject: Registration of new Channel Framework package
Package Name: msc-mixer/1.0
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]
Published Specification(s): RFCXXXX
Person & email address to contact for further information:
IETF, MEDIACTRL working group, (mediactrl@ietf.org),
Scott McGlashan (smcg.stds01@mcglashan.org).
8.2. URN Sub-Namespace Registration
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:msc-mixer", per the guidelines in RFC 3688
[RFC3688].
McGlashan, et al. Expires July 10, 2011 [Page 88]
Internet-Draft Mixer Control Package January 2011
URI: urn:ietf:params:xml:ns:msc-mixer
Registrant Contact: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Scott McGlashan
(smcg.stds01@mcglashan.org).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Media Control Channel Framework Mixer
Package attributes</title>
</head>
<body>
<h1>Namespace for Media Control Channel
Framework Mixer Package attributes</h1>
<h2>urn:ietf:params:xml:ns:msc-mixer</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]
<p>See RFCXXXX</p>
</body>
</html>
END
8.3. XML Schema Registration
This section registers an XML schema as per the guidelines in RFC
3688 [RFC3688].
URI: urn:ietf:params:xml:ns:msc-mixer
Registrant Contact: IETF, MEDIACTRL working group,
(mediactrl@ietf.org), Scott McGlashan
(smcg.stds01@mcglashan.org).
Schema: The XML for this schema can be found in
Section 5 of this document.
8.4. MIME Media Type Registration for 'application/msc-mixer+xml'
This section registers the "application/msc-mixer+xml" MIME type.
McGlashan, et al. Expires July 10, 2011 [Page 89]
Internet-Draft Mixer Control Package January 2011
To: ietf-types@iana.org
Subject: Registration of MIME media type
application/msc-mixer+xml
MIME media type name: application
MIME subtype name: msc-mixer+xml
Required parameters: (none)
Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is
UTF-8.
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 [RFC3023], section 3.2.
Security considerations: No known security considerations outside
of those provided by the Media Control Channel Framework Mixer
Package.
Interoperability considerations: This content type provides
constructs for the Media Control Channel Framework Mixer package.
Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification.]
Applications which use this media type: Implementations of
the Media Control Channel Framework Mixer package.
Additional Information: Magic Number(s): (none)
File extension(s): (none)
Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Scott
McGlashan <smcg.stds01@mcglashan.org>
Intended usage: LIMITED USE
Author/Change controller: The IETF
Other information: None.
McGlashan, et al. Expires July 10, 2011 [Page 90]
Internet-Draft Mixer Control Package January 2011
9. Change Summary
Note to RFC Editor: Please remove this whole section.
The following are the changes between the -14 and -13 versions
(addressing remaining IESG DISCUSS):
o 4.7.7 Language Identifier: deleted statement "where the language
code is required and a country code or other subtag identifier is
optional&1. Introduction
The IETF has specified datagram transport using UDP, SCTP, and DCCP,
as well as protocols layered on top of these transports (e.g., SCTP/
UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP
network layer. This document describes a robust method for Path MTU
Discovery (PMTUD) that can be used with these transport protocols (or
the applications that use their transport service) to discover an
appropriate size of packet to use across an Internet path.
1.1. Classical Path MTU Discovery
Classical Path Maximum Transmission Unit Discovery (PMTUD) can be
used with any transport that is able to process ICMP Packet Too Big
(PTB) messages (e.g., [RFC1191] and [RFC8201]). In this document,
the term PTB message is applied to both IPv4 ICMP Unreachable
messages (type 3) that carry the error Fragmentation Needed (Type 3,
Code 4) [RFC0792] and ICMPv6 Packet Too Big messages (Type 2)
[RFC4443]. When a sender receives a PTB message, it reduces the
effective MTU to the value reported as the Link MTU in the PTB
message. A method from time-to-time increases the packet size in
attempt to discover an increase in the supported PMTU. The packets
sent with a size larger than the current effective PMTU are known as
probe packets.
Packets not intended as probe packets are either fragmented to the
current effective PMTU, or the attempt to send fails with an error
code. Applications can be provided with a primitive to let them read
the Maximum Packet Size (MPS), derived from the current effective
PMTU.
Classical PMTUD is subject to protocol failures. One failure arises
when traffic using a packet size larger than the actual PMTU is
black-holed (all datagrams sent with this size, or larger, are
discarded). This could arise when the PTB messages are not delivered
back to the sender for some reason (see for example [RFC2923]).
Examples where PTB messages are not delivered include:
* The generation of ICMP messages is usually rate limited. This
could result in no PTB messages being generated to the sender (see
section 2.4 of [RFC4443])
* ICMP messages can be filtered by middleboxes (including firewalls)
[RFC4890]. A stateful firewall could be configured with a policy
to block incoming ICMP messages, which would prevent reception of
PTB messages to a sending endpoint behind this firewall.
Fairhurst, et al. Expires 24 September 2020 [Page 4]
Internet-Draft DPLPMTUD March 2020
* When the router issuing the ICMP message drops a tunneled packet,
the resulting ICMP message will be directed to the tunnel ingress.
This tunnel endpoint is responsible for forwarding the ICMP
message and also processing the quoted packet within the payload
field to remove the effect of the tunnel, and return a correctly
formatted ICMP message to the sender [I-D.ietf-intarea-tunnels].
Failure to do this prevents the PTB message reaching the original
sender.
* Asymmetry in forwarding can result in there being no return route
to the original sender, which would prevent an ICMP message being
delivered to the sender. This issue can also arise when policy-
based routing is used, Equal Cost Multipath (ECMP) routing is
used, or a middlebox acts as an application load balancer. An
example is where the path towards the server is chosen by ECMP
routing depending on bytes in the IP payload. In this case, when
a packet sent by the server encounters a problem after the ECMP
router, then any resulting ICMP message also needs to be directed
by the ECMP router towards the original sender.
* There are additional cases where the next hop destination fails to
receive a packet because of its size. This could be due to
misconfiguration of the layer 2 path between nodes, for instance
the MTU configured in a layer 2 switch, or misconfiguration of the
Maximum Receive Unit (MRU). If a packet is dropped by the link,
this will not cause a PTB message to be sent to the original
sender.
Another failure could result if a node that is not on the network
path sends a PTB message that attempts to force a sender to change
the effective PMTU [RFC8201]. A sender can protect itself from
reacting to such messages by utilizing the quoted packet within a PTB
message payload to validate that the received PTB message was
generated in response to a packet that had actually originated from
the sender. However, there are situations where a sender would be
unable to provide this validation. Examples where validation of the
PTB message is not possible include:
* When a router issuing the ICMP message implements RFC792
[RFC0792], it is only required to include the first 64 bits of the
IP payload of the packet within the quoted payload. There could
be insufficient bytes remaining for the sender to interpret the
quoted transport information.
Note: The recommendation in RFC1812 [RFC1812] is that IPv4 routers
return a quoted packet with as much of the original datagram as
possible without the length of the ICMP datagram exceeding 576
Fairhurst, et al. Expires 24 September 2020 [Page 5]
Internet-Draft DPLPMTUD March 2020
bytes. IPv6 routers include as much of the invoking packet as
possible without the ICMPv6 packet exceeding 1280 bytes [RFC4443].
* The use of tunnels/encryption can reduce the size of the quoted
packet returned to the original source address, increasing the
risk that there could be insufficient bytes remaining for the
sender to interpret the quoted transport information.
* Even when the PTB message includes sufficient bytes of the quoted
packet, the network layer could lack sufficient context to
validate the message, because validation depends on information
about the active transport flows at an endpoint node (e.g., the
socket/address pairs being used, and other protocol header
information).
* When a packet is encapsulated/tunneled over an encrypted
transport, the tunnel/encapsulation ingress might have
insufficient context, or computational power, to reconstruct the
transport header that would be needed to perform validation.
* A Network Address Translation (NAT) device that translates a
packet header, ought to also translate ICMP messages and update
the ICMP quoted packet [RFC5508] in that message. If this is not
correctly translated then the sender would not be able to
associate the message with the PL that originated the packet, and
hence this ICMP message cannot be validated.
1.2. Packetization Layer Path MTU Discovery
The term Packetization Layer (PL) has been introduced to describe the
layer that is responsible for placing data blocks into the payload of
IP packets and selecting an appropriate MPS. This function is often
performed by a transport protocol (e.g., DCCP, RTP, SCTP, QUIC), but
can also be performed by other encapsulation methods working above
the transport layer.
In contrast to PMTUD, Packetization Layer Path MTU Discovery
(PLPMTUD) [RFC4821] introduced a method that does not rely upon
reception and validation of PTB messages. It is therefore more
robust than Classical PMTUD. This has become the recommended
approach for implementing discovery of the PMTU [RFC8085].
It uses a general strategy where the PL sends probe packets to search
for the largest size of unfragmented datagram that can be sent over a
network path. Probe packets are sent to explore using a larger
packet size. If a probe packet is successfully delivered (as
determined by the PL), then the PLPMTU is raised to the size of the
Fairhurst, et al. Expires 24 September 2020 [Page 6]
Internet-Draft DPLPMTUD March 2020
successful probe. If no response is received to a probe packet, the
method then reduces the PLPMTU.
Datagram PLPMTUD introduces flexibility in implementation. At one
extreme, it can be configured to only perform Black Hole Detection
and recovery with increased robustness compared to Classical PMTUD.
At the other extreme, all PTB processing can be disabled, and PLPMTUD
replaces Classical PMTUD.
PLPMTUD can also include additional consistency checks without
increasing the risk that data is lost when probing to discover the
Path MTU. For example, information available at the PL, or higher
layers, enables received PTB messages to be validated before being
utilized.
1.3. Path MTU Discovery for Datagram Services
Section 5 of this document presents a set of algorithms for datagram
protocols to discover the largest size of unfragmented datagram that
can be sent over a network path. The method relies upon features of
the PL described in Section 3 and applies to transport protocols
operating over IPv4 and IPv6. It does not require cooperation from
the lower layers, although it can utilize PTB messages when these
received messages are made available to the PL.
The message size guidelines in section 3.2 of the UDP Usage
Guidelines [RFC8085] state "an application SHOULD either use the Path
MTU information provided by the IP layer or implement Path MTU
Discovery (PMTUD)", but does not provide a mechanism for discovering
the largest size of unfragmented datagram that can be used on a
network path. The present document updates RFC 8085 to specify this
method in place of PLPMTUD [RFC4821] and provides a mechanism for
sharing the discovered largest size as the MPS (see Section 4.4).
Section 10.2 of [RFC4821] recommended a PLPMTUD probing method for
the Stream Control Transport Protocol (SCTP). SCTP utilizes probe
packets consisting of a minimal sized HEARTBEAT chunk bundled with a
PAD chunk as defined in [RFC4820]. However, RFC 4821 did not provide
a complete specification. The present document replaces this by
providing a complete specification.
The Datagram Congestion Control Protocol (DCCP) [RFC4340] requires
implementations to support Classical PMTUD and states that a DCCP
sender "MUST maintain the MPS allowed for each active DCCP session".
It also defines the current congestion control MPS (CCMPS) supported
by a network path. This recommends use of PMTUD, and suggests use of
control packets (DCCP-Sync) as path probe packets, because they do
Fairhurst, et al. Expires 24 September 2020 [Page 7]
Internet-Draft DPLPMTUD March 2020
not risk application data loss. The method defined in this
specification can be used with DCCP.
Section 6 specifies the method for datagram transports and provides
information to enable the implementation of PLPMTUD with other
datagram transports and applications that use datagram transports.
Section 6 also provides updated recommendations for [RFC6951] and
[RFC8261].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terminology is defined. Relevant terms are directly
copied from [RFC4821], and the definitions in [RFC1122].
Acknowledged PL: A PL that includes a mechanism that can confirm
successful delivery of datagrams to the remote PL endpoint (e.g.,
SCTP). Typically, the PL receiver returns acknowledgments
corresponding to the received datagrams, which can be utilised to
detect black-holing of packets (c.f., Unacknowledged PL).
Actual PMTU: The Actual PMTU is the PMTU of a network path between a
sender PL and a destination PL, which the DPLPMTUD algorithm seeks
to determine.
Black Hole: A Black Hole is encountered when a sender is unaware
that packets are not being delivered to the destination end point.
Two types of Black Hole are relevant to DPLPMTUD:
* Packets encounter a packet Black Hole when packets are not
delivered to the destination endpoint (e.g., when the sender
transmits packets of a particular size with a previously known
effective PMTU and they are discarded by the network).
* An ICMP Black Hole is encountered when the sender is unaware
that packets are not delivered to the destination endpoint
because PTB messages are not received by the originating PL
sender.
Classical Path MTU Discovery: Classical PMTUD is a process described
in [RFC1191] and [RFC8201], in which nodes rely on PTB messages to
Fairhurst, et al. Expires 24 September 2020 [Page 8]
Internet-Draft DPLPMTUD March 2020
learn the largest size of unfragmented packet that can be used
across a network path.
Datagram: A datagram is a transport-layer protocol data unit,
transmitted in the payload of an IP packet.
Effective PMTU: The Effective PMTU is the current estimated value
for PMTU that is used by a PMTUD. This is equivalent to the
PLPMTU derived by PLPMTUD plus the size of any headers added below
the PL, including the IP layer headers.
EMTU_S: The Effective MTU for sending (EMTU_S) is defined in
[RFC1122] as "the maximum IP datagram size that may be sent, for a
particular combination of IP source and destination addresses...".
EMTU_R: The Effective MTU for receiving (EMTU_R) is designated in
[RFC1122] as the largest datagram size that can be reassembled by
EMTU_R (Effective MTU to receive).
Link: A Link is a communication facility or medium over which nodes
can communicate at the link layer, i.e., a layer below the IP
layer. Examples are Ethernet LANs and Internet (or higher) layer
and tunnels.
Link MTU: The Link Maximum Transmission Unit (MTU) is the size in
bytes of the largest IP packet, including the IP header and
payload, that can be transmitted over a link. Note that this
could more properly be called the IP MTU, to be consistent with
how other standards organizations use the acronym. This includes
the IP header, but excludes link layer headers and other framing
that is not part of IP or the IP payload. Other standards
organizations generally define the link MTU to include the link
layer headers. This specification continues the requirement in
[RFC4821], that states "All links MUST enforce their MTU: links
that might non- deterministically deliver packets that are larger
than their rated MTU MUST consistently discard such packets."
MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU that
DPLPMTUD will attempt to use.
MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that
DPLPMTUD will attempt to use.
MPS: MPS: The Maximum Packet Size (MPS) is the largest size of
application data block that can be sent across a network path by a
PL using a single Datagram.
Packet: A Packet is the IP header plus the IP payload.
Fairhurst, et al. Expires 24 September 2020 [Page 9]
Internet-Draft DPLPMTUD March 2020
Packetization Layer (PL): The PL is a layer of the network stack
that places data into packets and performs transport protocol
functions. Examples of a PL include: TCP, SCTP, SCTP over DTLS or
QUIC.
Path: The Path is the set of links and routers traversed by a packet
between a source node and a destination node by a particular flow.
Path MTU (PMTU): The Path MTU (PMTU) is the minimum of the Link MTU
of all the links forming a network path between a source node and
a destination node, as used by PMTUD.
PTB_SIZE: The PTB_SIZE is a value reported in a validated PTB
message that indicates next hop link MTU of a router along the
path.
PL_PTB_SIZE: The size reported in a validated PTB message, reduced
by the size of all headers added by layers below the PL.
PLPMTU: The Packetization Layer PMTU is an estimate of the largest
size of PL datagram that can be sent by a path, controled by
PLPMTUD.
PLPMTUD: Packetization Layer Path MTU Discovery (PLPMTUD), the
method described in this document for datagram PLs, which is an
extension to Classical PMTU Discovery.
Probe packet: A probe packet is a datagram sent with a purposely
chosen size (typically the current PLPMTU or larger) to detect if
packets of this size can be successfully sent end-to-end across
the network path.
Unacknowledged PL: A PL that does not itself provide a mechanism to
confirm delivery of datagrams to the remote PL endpoint (e.g.,
UDP), and therefore requires DPLPMTUD to provide a mechanism to
detect black-holing of packets (c.f., Acknowledged PL).
3. Features Required to Provide Datagram PLPMTUD
The principles expressed in [RFC4821] apply to the use of the
technique with any PL. TCP PLPMTUD has been defined using standard
TCP protocol mechanisms. Unlike TCP, a datagram PL requires
additional mechanisms and considerations to implement PLPMTUD.
The requirements for datagram PLPMTUD are:
1. Managing the PLPMTU: For datagram PLs, the PLPMTU is managed by
DPLPMTUD. A PL MUST NOT send a datagram (other than a probe
Fairhurst, et al. Expires 24 September 2020 [Page 10]
Internet-Draft DPLPMTUD March 2020
packet) with a size at the PL layer that is larger than the
current PLPMTU.
2. Probe packets: On request, a DPLPMTUD sender is REQUIRED to be
able to transmit a packet larger than the PLMPMTU. This is used
to send a probe packet. In IPv4, a probe packet MUST be sent
with the Don" and clarified that RFC 4647 specifies the matching
procedure.
The following are the changes between the -13 and -12 versions
(addressing remaining IESG DISCUSS):
o 4.0, 4.1, etc: Added language tags to identify the language of
descriptive text attributes. A desclang attribute is added to the
root element and has a default value of i-default. Subordinate
elements with descriptive text attributes also have this attribute
defined - if it is not specified on the subordinate element, then
the desclang value on the root element applies. Added example of
desclang in 4.1.
o 5: Updated schema with desclang attributes
o Section 4.7.6: Corrected ABNF definition of IANA MIME media type
to allow parameter values.
The following are the changes between the -12 and -11 versions
(primarily addressing IESG DISCUSS, comments and nits):
o Introduction: Clarified that Control Framework is an equivalent
term for the Media Control Channel Framework.
o 4.2.4.2, 4.2.4.3, 4.5: Replaced reference to standards-tracks RFC
for assignment of new values, with reference to using Standards
Action process defined in RFC 5226.
o 4.0: Clarified that while some elements contain attributes whose
value is descriptive text, this descriptive text is for diagnostic
use only and does not require a language indicator such as a
language tag.
o 4.2.2.5.2: expanded DTMF acronym.
o 4.2.1.4.2.1: Changed <video-layout> so that the layout is a child
element rather than content value. Changed examples to match.
Updated XML schema.
McGlashan, et al. Expires July 10, 2011 [Page 91]
Internet-Draft Mixer Control Package January 2011
o 4.2.1.4.3: Changed <video-switch> so that the policy is a child
element rather than content value. Changed examples to match.
Updated XML schema.
o 4.4.1: changed <codec> to include name attribute; aligned
definition with RFC4288; updated XML schema.
o 4.2.2.5: Clarified that the media attribute of <stream> is a MIME
type-name with reference to RFC 4288.
o 4.5.1: Added encoding attribute to <param> to allow for
specification of content-transfer-encoding schema. Updated XML
schema.
o 4.5.1: Simplified content model of <param> to be text only.
Updated XML schema.
o 4.6.6: Clarified MIME media type format with ABNF production
referencing RFC 4288.
o 4.2.2.5.3: clarified the definition of <region> as an area in a
video layout
o 5: Stated that the schema is normative.
o 5: Corrected default value of tones attribute in schema to match
definition in 4.2.2.5.2.
o 4.6: Type definitions; added references to XML Schema datatypes
where appropriate; changed definition of boolean to match W3C
definition and updated boolean type in schema.
o Typos: in 4.2.1.4.2.1, added '/' to <video-layout>; in 4.2.1.4.3
<video-switch>, replaced second <join> with <unjoin>; in 4.2.3,
corrected code and status in <response> examples;
o Validated all examples against XML schema and corrected where
necessary.
The following are the changes between the -11 and -10 versions
(addressing IETF Last Call comments):
o 4.2.2.3: For <modifyjoin>, removed the statement "It MUST NOT
change the configuration of any streams not included as child
elements." since modifications in stream directionality can affect
other streams of the same type.
McGlashan, et al. Expires July 10, 2011 [Page 92]
Internet-Draft Mixer Control Package January 2011
o 4.2.2.5.2: Changed definition of tones attribute of <clamp>
element so that if the element is specified, then all DTMF tones
are clamped by default. Updated XML schema.
o 7: Corrected references from Section 11 to Section 12 in Control
Framework.
o Fixed various typos.
The following are the changes between the -10 and -09 versions:
o References: Moved the XCON reference to the Normative References
section.
o 4.2: Mixer Elements: clarified that when a requested mixer
operation (partially) fails, the MS carries out no part of the
operation and sends an error response.
The following are the changes between the -09 and -08 versions
following shepherd writeup:
o 4.2.4.1.1: <active-talker>: Removed the statement that it is an
error if an <active-talker> element has both connectionid and
conferenceid attributes specified because the AS always sends a
framework 200 in response to notification events, including active
talker events. Instead, clarified that no active talker is
described if both attributes are specified or if neither attribute
is specified.
o Various spelling and grammatical errors fixed.
The following are the changes between the -08 and -07 versions.
o 8.4: Changed file extension from '.xml' to (none)
o Changed "~" to a ":" for connectionid
o 4.2.6.1: Clarified that <param> can contain an XML value.
o 4.2.4.2: Changed <unjoin-notify> status codes so that only 0-2
defined and all others are reserved for future use requiring a
standard-track RFC.
o 4.2.4.3: Changed <conferenceexit> status codes so that only 0-2
defined and all others are reserved for future use requiring a
standard-track RFC.
McGlashan, et al. Expires July 10, 2011 [Page 93]
Internet-Draft Mixer Control Package January 2011
o 4.5: Changed status code for <response> and <auditresponse> so
that certain codes are defined and all others are reserved for
future use requiring a standard-track RFC.
The following are the changes between the -07 and -06 versions.
o Generally corrected references from Section 17.1 to Section 16.1
of Control Channel Framework.
o 4.2.2.2: removed "is" in "unless this is leads to a stream
conflict"
o 4.2.2.3: corrected error code from 408 to 409 for "If the
specified entities are not already joined, then the MS reports an
error (408)."
o 4.2.1.4.3: corrected error code from 409 to 424 for "If the MS
does not support the specified video switching policy or ..., then
MS reports a 409 error".
o 4.2.1.4.2: corrected error code from 408 to 423 for "If the MS
does not support video conferencing at all, or ...., the MS
reports an 408 error ..."
o 4.2.1.1, 4.2.1.2, 4.2.2.2, 4.2.2.3: Clarified that <codecs>
specified in <createconference> or <modifyconference> impose a
limitation in the media capability of a conference and this
limitation affects whether the conference can be <join> or
<modifyjoin>ed to another entity.
The following are the changes between the -06 and -05 versions.
o 4.4.1: <codec>: corrected typos, added an example of <params>
usage, added a <subtype> section and moved the <params> section
inside this section.
o 8: IANA Considerations: Updated IANA registration information and
added registration for the XML Schema
The following are the changes between the -05 and -04 versions.
o Schema: Fixed problem with non-deterministic content models.
o 7. Security Considerations: Added requirement that
implementations need to secure SIP and RTP sessions with User
Agents.
The following are the changes between the -04 and -03 versions.
McGlashan, et al. Expires July 10, 2011 [Page 94]
Internet-Draft Mixer Control Package January 2011
o 4.2.1.4.3: corrected typo
o 4.2.2.3: Clarified the behavior of <modifyjoin> for cases where
each direction of a stream is independently controlled.
o 4.2.2.5: Corrected syntax error in examples.
o 4.2.2.5.1: Clarified that when an audio stream is in the muted
state, then a <volume> automatic or setgain control causes the
state to change automatically to unmuted.
o 7 Security: Clarified that both conference and join mixers are
covered by the package security policies.
o 7 Security: Added a denial of service example where the attacker
impersonates the MS.
o 7 Security: Clarified that the package security policy for
multiple channels is only useful if the channels themselves are
secured.
o Updated acknowledgements.
The following are the major changes between the -03 and -02 versions.
o Corrected various typos and nits.
o Conformance language: Removed unnecessary MUSTs, especially for
error codes. Changed most RECOMMENDEDs to MUST or MAY. Removed
lowercase 'should', 'must' and 'may'.
o Tidied up Abstract
o Removed old Introduction section (it just duplicated the
abstract). Replaced it with the old Overview Section. Section
numbering changed!
o Introduction: Clarified which MediaCtrl Requirements are satisfied
by this package.
o 4.2.1.1: <createconference>: Clarified that an attempt to create a
conference with an identifier already used by an existing
conference does not affect the existing conference (405 error
response).
o 4.2.1.4.1: <audio-mixing>: Added a 'n' attribute for the number of
participants to be included in nbest audio mixing.
McGlashan, et al. Expires July 10, 2011 [Page 95]
Internet-Draft Mixer Control Package January 2011
o 4.2.1.4.3: <video-switch>: Clarified that the active speaker in
video switching is the loudest speaker.
o 4.2.1.4.4: <subscribe>: Clarified that if a subscription specified
in a foreign namespace element or attribute is not supported by
the MS, then the MS generates a 428 error response. Changed
conformance support for <active-talkers-sub> from SHOULD to MUST.
Removed 422 error response.
o 4.2.2: Joining Elements: Added text to the empty section.
o 4.2.2.2, 4.2.2.3, 4.2.2.4: <join>, <modifyjoin> and <unjoin>:
Clarified that join operation failures do not affect existing
stream properties of the entities (407 and new 422 error
response). Clarified stream failure errors in <modifyjoin> and
<unjoin>.
o 4.2.2.2: <join>. Clarified that <stream> elements can be used to
independently control properties of the media flow in different
directions. Added a response code (422) for when the MS does not
support a media stream configuation.
o 4.2.2.2: <join>. Clarified that error responses are generated if
id1 or id2 reference a conference or connection which does not
exist. Added an error status code (412) for non-existant
connections.
o 4.2.2.5: <stream>: Changed the definition so that in each child
element, the media stream affected is indicated by the value of
the direction attribute of the parent element. Added examples of
controlling the media flow properties.
o 4.2.4.2: <unjoin-notify>. Added reserved range of status codes.
Changed code from 1 to 0 for the unjoin case. Changed code from 3
to 1 for execution error.
o 4.2.4.3: <conferenceexit>. Added reserved range of status codes.
Changed code from 1 to 0 for the destroyconference case (align
with IVR). Added a code for conference exiting due to exceeding
its maximum duration.
o Schema: Adding missing version attribute on <mscmixer>.
o Security Considerations: Major update. Added examples showing
malicious attacks when channel security is not correctly
addressed. Added more details on multiple channel cases including
administrator and monitor channels as well as channel handover.
McGlashan, et al. Expires July 10, 2011 [Page 96]
Internet-Draft Mixer Control Package January 2011
o Removed affliations in Contributors section.
The following are the major changes between the -02 and -01 versions.
o Section 4: Aligned Control Package definitions with requirements
in Section 8 of the Control Framework.
o Following October Interim meeting discussion on response codes,
generally clarified usage of error status codes, modified some
codes and re-organized the response codes section (Section 4.6)
with more guidance and details.
o MIXER-006. No action required following October 2008 interim
discussion.
o MIXER-008. No action required following October 2008 interim
discussion.
o MIXER-009. No action required for control package - addressed in
-05 framework draft following interim October 2008 discussion.
o MIXER-010/5.2.2.5: Clarified that in the <stream> element, an
"inactive" direction value indicates the stream is established but
there is no media flow. Such a stream can be manipulated by
<modifyjoin> and <unjoin>.
o 5.2.2.5: <stream>: Clarified that the media stream specified in
child elements <volume>, <clamp>, <region> and <priority> is the
stream originating from the entity identified as id1.
o 5.2.1.4.3: <video-switch>: Clarified that it is not an error if a
<stream> specifies a region which is not defined for the currently
active video layout.
o 5.2.1.4.2.1: <video-layout>: Added descriptions and ASCII art for
layout and regions of XCON video layouts.
o Added examples of audio conferencing, connection bridging and
video conferencing.
The following are the major changes between the -01 and -00 versions.
o [MIXER-001]/5.2.4.3: Added <conferenceexit> notification event.
o [MIXER-003]/5.2.1.4.2.1: Added ASCII diagrams for video layouts.
o [MIXER-004]/5.3.2.2.1: Added active <video-layout> information to
<conferenceaudit>.
McGlashan, et al. Expires July 10, 2011 [Page 97]
Internet-Draft Mixer Control Package January 2011
o [MIXER-007]/5.4.1: Added <params> inside <codec> so additional
codec information can be specified.
o 5.2.1.1: Fixed <createconference> example with missing min-
participants attributes.
o 5: Changed handling of unsupported foreign namespace elements and
attributes. The MS send a 427 error response if it encounters
foreign elements and attributes it does not support.
o 5.2.1.4.3: <video-switch>. Clarified that the VAS policy is
implementation-specific if a participant provides more than one
audio stream.
o 5.2.2.2/5.2.2.3/5.2.2.4: Clarified that joining behavior so that
streams which have previously been <modifiedjoin>ed or <unjoin>ed
are not affected by a general <unjoin>.
o 5.2.1.4.3: <video-switch>: Added support for whether active
speaker is displayed on their video layout ('activespeakermix'
attribute) and clarified that personal video mixes are out of
scope for this package.
o 5.2.1.4.3/5.2.2.5.4: <video-switch>: Added support for a priority
mechanism in video switching policy and a <priority child element
on <stream>.
o 8:Updated security section
o 13:Updated references
o 5.2.1.4.4.1: Added default of 3 seconds for <active-talkers-sub>
interval.
o 5.2.2.5.1: <volume> controltype attribute set to mandatory.
o Updated schema
The following are the major changes between the -00 of this work
group item draft and the individual submission -04 version.
o Control package name is now 'msc-mixer/1.0'. Namespace is now
'urn:ietf:params:xml:ns:msc-mixer'. Mime type is now
'application/msc-mixer+xml'.
o Added XML root element <mscmixer>.
McGlashan, et al. Expires July 10, 2011 [Page 98]
Internet-Draft Mixer Control Package January 2011
o Editorial tidy up of sections.
o Added audit request/response elements.
o Added video layout and switching conference configuration.
o <audio-mixing>: changed 'mix-type' attribute to 'type'
(consistency with video-switch)
o Added "inactive" as value of <stream>'s direction attribute.
o Added <region> child to <stream> element.
o <createconference>: <audio-mixing> element is no longer mandatory;
added <video-layouts> and <video-switch> child elements. reserved-
talkers and reserved-listeners as attributes.
o replaced conf-id attribute with conferenceid attribute.
o Removed <data> element. Active talkers subscription and
notifications used dedicated elements now.
o Added <unjoin-notify> notification event to indicate when
(un)expected joins occur. Use case: connection or conference
joined to a conference and conference exits (either by request or
runtime error.
The following are the major changes between the -04 of the draft and
the -03 version.
o Updated reference for Media Control Channel Framework
The following are the major changes between the -03 of the draft and
the -02 version.
o None
The following are the major changes between the -02 of the draft and
the -01 version.
o clarified the model for join operations and introduced several new
package error codes
o added definition for MS connection
The following are the major changes between the -01 of the draft and
the -00 version.
McGlashan, et al. Expires July 10, 2011 [Page 99]
Internet-Draft Mixer Control Package January 2011
o restructured into single request response model for non-trivial
operations
o aligned with XML structure of other control framework packages
McGlashan, et al. Expires July 10, 2011 [Page 100]
Internet-Draft Mixer Control Package January 2011
10. Contributors
Asher Shiratzky provided valuable support and contributions to early
versions of this document.
The authors would like to thank the Mixer design team consisting of
Roni Even, Lorenzo Miniero, Adnan Saleem, Diego Besprosvan and Mary
Barnes who provided valuable feedback, input, diagrams and text to
this document.
McGlashan, et al. Expires July 10, 2011 [Page 101]
Internet-Draft Mixer Control Package January 2011
11. Acknowledgments
The authors would like to thank Roni Even, Lorenzo Miniero, Steve
Buko and Stephane Bastien for expert reviews of this work.
Shawn Emery carried out a thorough security review.
McGlashan, et al. Expires July 10, 2011 [Page 102]
Internet-Draft Mixer Control Package January 2011
12. References
12.1. Normative References
[I-D.ietf-mediactrl-sip-control-framework]
Boulton, C., Melanchuk, T., and S. McGlashan, "Media
Control Channel Framework",
draft-ietf-mediactrl-sip-control-framework-12 (work in
progress), September 2010.
[I-D.ietf-xcon-common-data-model]
Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized
Conferencing (XCON)", draft-ietf-xcon-common-data-model-22
(work in progress), December 2010.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
BCP 47, RFC 4647, September 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
McGlashan, et al. Expires July 10, 2011 [Page 103]
Internet-Draft Mixer Control Package January 2011
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E.,
and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Third Edition)", W3C Recommendation, February 2004.
[XMLSchema:Part2]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C Recommendation, October 2004.
12.2. Informative References
[IANA] "IANA registry for RTP Payload Types",
<http://www.iana.org/assignments/rtp-parameters>.
[MIME.mediatypes]
"IANA registry for MIME Media Types",
<http://www.iana.org/assignments/media-types/>.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 5022,
September 2007.
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol
Requirements", RFC 5167, March 2008.
[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
Language (MSML)", RFC 5707, February 2010.
McGlashan, et al. Expires July 10, 2011 [Page 104]
Internet-Draft Mixer Control Package January 2011
Authors' Addresses
Scott McGlashan
Hewlett-Packard
Email: smcg.stds01@mcglashan.org
Tim Melanchuk
Rain Willow Communications
Email: tim.melanchuk@gmail.com
Chris Boulton
NS-Technologies
Email: chris@ns-technologies.com
McGlashan, et al. Expires July 10, 2011 [Page 105]