Ieee 1733 Working Requirement & Assumptions Last Updated: Feb 22




Yüklə 6.24 Kb.
tarix17.04.2016
ölçüsü6.24 Kb.
IEEE 1733 Working Requirement & Assumptions

Last Updated: Feb 22nd, 2008 (during Salt Lake City F2F)
 
•         The 1733 header (the RTP header fields plus those added by 1733) shall have a fixed length.  This means that an RTP Mixer is DISALLOWED
•         Proposed requirement:  CC is always zero.  This implies that the CSRC field is always empty/zero length, implies that RTP mixing (which is really “merging”) is not allowed.
•         Proposal: We will keep the timestamp field in RTP header (e.g. sample count), but will add an 802.1AS timestamp in our 1733 header that correlates 802.1AS time to the RTP timestamp (i.e. it’s the cross-timestamp).
•         Proposal: The 802.1AS time is the ‘presentation time’ not the ‘sampled-at time’ associated with the packet.
•         Question:  Does anyone use the RTP header extension?  It looks like no RFC does.
•         Question:  Should we encapsulate standard payload types in a new payload type which includes a new header, or should we add an extension header?  We say ‘the former’.
•         Idea:  Use RTCP to establish a 1:1 correlation between 802.1Qat StreamID and the SSRC/session ID.
–        Need interface to initiate a 802.1Qat reservation.
•         1733 application asks SRP for reservation, gets streamID which it passes as it opens the socket. Alternatively, could (bad idea probably) pass it along with each RTP packet.
–        The applications communicate information in the same say as it communicates QoS i.e. the layer-2 UserPriority.
•         Statement of belief:  StreamID is 6B of SMAC (not necessarily of talker or listener) plus a SMAC-host-unique identifier
•         We may need an annex which tells how to map a host-unique SSRC+SessionID into a stream-ID.
•         NOTE:  1733 applications may make use of existing methods to map between L2 and L3 addresses
•         Question:  Would it be valuable to make it possible for a bridge to police AVB streams on a per-stream basis?  If yes, how do we do it without requiring the bridge to know where the 1722 StreamID and the 1733 StreamID, etc?
–        Possible solutions:  Use DMAC+Priority (only for multicast DMAC), new tag (like VLAN), 1st bridge polices per ingress port (talker) on the edge of the AVB cloud, require the talker station to shape per flow.
•         Assumption of AVB:  It will be possible to find out (from a bridge) which streams are 802.1Qat-admitted on a link, and the TSpec for each?
•         RTCP packets are sent best-effort (i.e. not AVB streams)
•         1733 does not say anything about RTSP. RTSP is out of scope


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©azrefs.org 2016
rəhbərliyinə müraciət

    Ana səhifə