| AEON | P. Martinsen, Ed. |
| Internet-Draft | Cisco |
| Intended status: Standards Track | January 27, 2014 |
| Expires: July 31, 2014 |
Markings for Enhancing Multiplexed Ordonance (MEMO)
draft-martinsen-aeon-memo-00
To make sure an clients mediastream is treated the best way possible by the network it is necsesary for the agent to provide hints. Such hints can be on individual packet level in for example a video stream describing how important a packet id for decoding the stream. Also with multiplexing technologies like BUNDLE [I-D.holmberg-mmusic-sdp-bundle-negotiation] individual frame marking might help the network to provide a better service to the client. This specification decribes how a small shim packet can be used for such fram markings in attition to how to make sure the remote client and the network path also support the markings.
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].
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 July 31, 2014.
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.
More text to be added here..
STUN messages are encoded in binary using network-oriented format (most significant byte or octet first, also commonly known as big- endian). The transmission order is described in detail in Appendix B of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are in decimal (base 10).
The MEMO header fields are using the same machensisms defined in STUN RFC 5389 [RFC5389] to make it easy to distinguish the shim packet in a stream. The Magic Cookie is shorter, and is its most important function is to avoid the shim packet to be wrongly reqognized as a STUN packet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| Type | sid |TBD| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Specific | Network feedback (TBD) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MEMO Header
Description of the fields:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MEMO Header Type Generic Field
If the type field in the header is Generic (0x0) the type specific field will contain the infomation defined as follows. (TODO: What can we do with a generic header? Discardable? Discardable, but expect a retransmit? Other smart stuff we can put in here?)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MEMO Header Type Audio Field
If the type field in the header is Audio (0x1) the type specific field will contain the infomation defined as follows.(Todo: Shold this contain information about audio behaviour, static vs elastic? (Opus is elastic?))
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|S| TID |FTYPE| PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: MEMO Header Type Video Field
If the type field in the header is Video (0x2) the type specific field will contain the infomation defined as follows. This field have also been fefined in [I-D.avtext-berger-framemarking].
Description of the fields:
Before starting to use the shim packet remote agent support MUST be verified. It is also usefull to probe the network for any nodes that support processing the MEMO shim packet. Verification that no network elements block traffic containig the MEMO shim packet SHOULD also be done.
Remote agent and path support is detected by adding a STUN attributes to the STUN connectivity cheks when ICE [RFC5245] probes the possible open network paths. Validation of a unbloked network path for MEMO packets is done by adding the MEMO shim packet to the STUN packets sent when ICE is nominating a candidate.
Add MEMO shim layer before the STUN Binding Request. All in same UDP packet.
All in paralell, just in responses (and then check oposite direction when nominating?). Or can we expect the path to support this if the STUN packet goes through. Could define a STUN attribute that we can add after the integrity attribute to learn about the path and support for MEMO.
Want to use ICE. As this is nice input to the ICE machinery. Especially if we use the onfo attribute.
Keep the packet as small as possible. Use attributes only when it is smart (tm) to do so.
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=2 | L=2 |D|S|TID |Type | video codec specific information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Video Codec
Network nodes can ask agents to pad the MEMO packets with empty path attributes. If MEMO packets contains a Path Information attribute it can be used by the network node to covey useful information regarding packet loss and other things to the agent. (Need to open up the agregated discussion)
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| typ | len | What do we do here? |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Path Information
This specification definew two new attributes, MEMO-SUPPORT and MEMO-INFO.
The MEMO-SUPPORT attribute indicates that the agent sending this connectivity check or response supports MEMO. The attribute has no content (the Length field of the attribute is zero); it serves as a flag. It has an attribute value of 0x00XX.
Probably lots of things that can go very wrong....
txt
Authors would like to thank someone..
| [RFC0791] | Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5245] | Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. |
| [RFC5389] | Rosenberg, J., Mahy, R., Matthews, P. and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. |
| [I-D.avtext-berger-framemarking] | Berger, E. and S. Nandakumar, "Frame marking for RTP packets", Internet-Draft draft-avtext-berger-framemarking-00, October 2013. |
| [I-D.holmberg-mmusic-sdp-bundle-negotiation] | Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", Internet-Draft draft-holmberg-mmusic-sdp-bundle-negotiation-00, October 2011. |