<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
      please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc ipr="trust200902"  docName="draft-dong-priority-rtp-packet-02" category="info">
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="draft-dong-priority-rtp-packet"> 
    Discarding Priority of RTP Video Packets    
    </title>

    <author fullname="Lijun Dong" initials="L." surname="Dong">
      <organization>Futurewei Technologies Inc.</organization>

      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>United States of America</country>
        </postal>
        <email>lijun.dong@futurewei.com</email>
      </address>
    </author>
	
	

    <author fullname="Richard Li" initials="R." surname="Li">
      <organization>Futurewei Technologies Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>United States of America</country>
        </postal>
        <email>richard.li@futurewei.com</email>
      </address>
    </author>

    <author fullname="Stuart Clayman" initials="S." surname="Clayman">
      <organization>University College London</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>United Kingdom</country>
        </postal>
        <email>s.clayman@ucl.ac.uk</email>
      </address>
    </author>

    <author fullname="Muge Sayit" initials="M." surname="Sayit">
      <organization>Ege University</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Turkey</country>
        </postal>
        <email>mugefesci@gmail.com</email>
      </address>
    </author>

    <date/>

    <area>ops</area>

    <workgroup>Independent Submission</workgroup>

    <keyword>Internet-Draft</keyword>

<abstract>
<t>
This document illustrates that significance difference or discarding priority might exist among RTP packets which encapsulate video streaming data with the existing modern video codecs, i.e., H.264/AVC, SVC, H.265/HEVC and H.266/VVC. 
</t>
<t>
The document overviews the RTP NALU header format for the existing modern video codecs. Each contains at least one field that indicates the RTP packet's relative significance within the video stream. With the dominance of video traffic in the Internet, selectively dropping RTP packets from competing video streams according to their significances or discarding priorities could be a complementary mechanism when dealing with network congestion.  The document proposes the Differentiated Services Code Point (DSCP) value mapping to the RTP packet discarding priority carried in the RTP NALU header. 
The document also proposes a new Hop-by-Hop Extension Header (HbH-EH) with a value that is copied from the discarding priority of the RTP packet, if the 6-bit DSCP value is not long enough for the mapping.  
</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
    <t>
    The modern video codecs, e.g., H.264/AVC <xref target="H.264"/>, SVC <xref target="H.264"/>, H.265/HEVC <xref target="H.265"/>, and H.266/VVC <xref target="ISO23090-3"/> <xref target="VVC"/>use the NAL-unit-based syntax structure. The NAL unit structure provides convenient packetization/framing of video data to be transmitted in packet-based systems using transport protocols such as RTP <xref target="RFC3550"/>. The transport layer can identify the boundaries among adjacent NAL units without use of start code. Therefore, the overhead for these start codes can be eliminated. Depending on the characteristics of the NAL unit(s) encapsulated in a RTP packet, the priority/importance of RTP packets from the same video streaming flow could differ from each other. In the following, we firstly overview how the priority information is carried in RTP packets for H.264/AVC, SVC, H.265/HEVC, and H.266/VVC by referring to <xref target="RFC6184"/> <xref target="RFC6190"/> <xref target="RFC7798"/> <xref target="RTP.VVC"/> respectively. Next we discuss how to make the network layer aware of and utilize such priority information for selective packet dropping when network congestion happens and outgoing buffer overflows.
    </t> 	
	
</section>

<section title="Terms and Abbreviations">
     <t>The terms and abbreviations used in this document are listed below.
       <list style="symbols">   
         <t>AF: Assured Forwarding</t>
         <t>AP: Aggregation Packet</t>    
         <t>AVC: Advanced Video Coding</t>
         <t>DF: Default Forwarding</t>
         <t>DSCP: Differentiated Services Code Point</t>
         <t>EF: Expedited Forwarding</t>
         <t>HDTV: High Definition Television</t>
         <t>HEVC: High Efficiency Video Coding</t>
         <t>HbH-EH: Hop-by-Hop Extension Header</t>
         <t>IDR: Instantaneous Decoding Refresh</t>
         <t>FU: Fragmentation Unit</t>
         <t>MANE: Media Aware Network Element</t>
         <t>MTAP: Multi-Time Aggregation Packet</t>
         <t>NAL: Network Abstract Layer</t>
         <t>PACI: PAyload Content Information</t>
         <t>PHB: Per Hop Behavior</t>
         <t>QoE: Quality of Experience</t>
         <t>QoS: Quality of Service</t>
         <t>RTP: Real Time Protocol</t>
         <t>STAP: Signal-Time Aggregation Packet</t>
         <t>SNR: Signal-to-Noise Ratio</t>
         <t>SVC: Scalable Video Coding</t>
         <t>VCL: Video Coding Layer </t>

         
      </list>
     </t>

    

    <t>The above terminology is defined in greater details in the remainder of this document.
    </t>
</section>




<section title="Packet Level Priority">
<t>
For different versions of video encoding schemes, the RTP packet payload format has been and is being standardized. Within a video flow, the importance or discarding priority can differ among different RTP packets, depending on the NAL unit(s) encapsulated in the RTP packets. In the following, we give a brief overview of such property, which is shown in different versions of video encoders. 
</t>

<section anchor="H264" title="Packet Level Priority Difference in H.264 RTP Packets">

<t>
The H.264 video codec <xref target="H.264"/> has a very broad application range that covers all forms of digital compressed video, from low bitrate Internet streaming applications to HDTV broadcast and digital cinema applications with nearly lossless coding. The coded video data is organized into NAL units, each of which contains an integer number of bytes. The H.264/AVC specification adopts a byte stream format. Each NAL unit has a prefix of a specific pattern of three bytes, which is called a start code prefix. The boundaries of the NAL unit can then easily be detected by searching the coded data for this unique start code prefix pattern. A set of NAL units in a specified form comprises as an access unit. The decoding of each access unit results in one decoded picture. 
</t>

<t>
The syntax and semantics of the NAL unit type octet are specified in <xref target="H.264"/>,  includes the essential properties of the NAL unit type octet in the NAL unit header. The RTP packet for H.264 video <xref target="RFC6184"/> inherits the same NAL unit header. As shown in <xref target="H264NALUHeader"/>, the 2 bits NRI field (i.e., nal_ref_idc) indicates the relative importance/transport priority of the NRI unit determined by the encoder. A value of 00 indicates that the content of the NAL unit is not used to reconstruct reference pictures for inter picture prediction.  Such NAL units can be discarded without risking the integrity of the reference pictures.  Values greater than 00 indicate that the decoding of the NAL unit is required to maintain the integrity of the reference pictures.  The H.264 specification requires that the value of NRI SHALL be equal to 0 for all NAL units having nal_unit_type equal to 6, 9, 10, 11, or 12. For NAL units having nal_unit_type equal to 7 or 8 (indicating a sequence parameter set or a picture parameter set, respectively), an H.264 encoder should set the value of NRI to '11'.  For coded slice NAL units of a primary coded picture having nal_unit_type equal to 5 (indicating a coded slice belonging to an IDR picture), an H.264 encoder sets the value of NRI to '11'. Non-IDR coded slice is specified with '10' NRI value, coded slice data partition A has '10' NRI value, while partition B and C have '01' NRI value.
</t>

<figure anchor="H264NALUHeader"><artwork><![CDATA[
                +---------------+
                |0|1|2|3|4|5|6|7|
                +-+-+-+-+-+-+-+-+
                |F|NRI|  Type   |
                +---------------+

       The Structure of the H.264 NAL Unit Header.
]]></artwork></figure>



<t>
The 'Type' field indicates the payload format with three different basic payload structures: 
<list style="symbols">
    <t>Single NAL Unit Packet: Contains only a single NAL unit in the payload. The NRI field is associated with this single NAL unit.  </t>
    <t> Aggregation Packet (AP): Packet type used to aggregate multiple NAL units into a single RTP payload. This packet exists in four versions, the Single-Time Aggregation Packet type A (STAP-A), the Single-Time Aggregation Packet type B (STAP-B), Multi-Time Aggregation Packet (MTAP) with 16-bit offset (MTAP16), and Multi-Time Aggregation Packet (MTAP) with 24-bit offset (MTAP24). A NAL unit header is followed by one or more NAL units in aggregation packets. The value of NRI is the maximum of all the NAL units carried in the aggregation packet.</t> 
	<t>Fragmentation Unit (FU): Used to fragment a single NAL unit over multiple RTP packets. It exists with two versions, FU-A and FU-B respectively. Each FU packet has a FU indicator which has the same format as above. The value of the NRI field is set according to the value of the NRI field in the fragmented NAL unit, which means all the FU packets belong to the same NAL unit have the same NRI value.</t> 		  
</list>       
</t>
</section>

<section anchor="SVC" title="Packet Level Priority Difference in SVC RTP Packets">
<t>
Scalable Video Coding (SVC) extension of the H.264/AVC video coding standard  is specified in Amendment 3 to ISO/IEC 14496 Part 10 <xref target="ISO/IEC14496-10"/> and equivalently in Annex G of ITU-T Rec. H.264 <xref target="H.264"/>. SVC defines a coded video representation in which a given bitstream offers representations of the source material at different levels of scalability: spatial (picture size), quality (or Signal-to-Noise Ratio (SNR)), and temporal (pictures per second). Bitstream components associated with a given level of spatial, quality, and temporal fidelity are identified using corresponding parameters in the bitstream: dependency_id, quality_id, and temporal_id. There are three additional octets in the NAL unit header of SVC RTP packets <xref target="RFC6190"/>, which are shown in <xref target="SVCEH"/>.
</t>

<figure anchor="SVCEH"><artwork><![CDATA[
            +---------------+---------------+---------------+
            |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |R|I|   PRID    |N| DID |  QID  | TID |U|D|O| RR|
            +---------------+---------------+---------------+
               
               Additional Octets in the SVC NAL Unit Header.
            
]]></artwork></figure>


<t>
The priority of a NAL unit in SVC video stream can be further specified by the priority_id field (PRID), which has 6 bits. A lower value of PRID indicates a higher priority.
</t>
</section>

<section anchor="H265" title="Packet Level Priority Difference in H.265 RTP Packets">
<t>
The H.265/HEVC <xref target="H.265"/> significantly improves coding efficiency over H.264. Similarly, H.265 also includes a Video Coding Layer (VCL), which is often used to refer to the coding-tool features, and a Network Abstraction Layer (NAL), which is often used to refer to the systems and transport interface aspects of the codecs. HEVC includes an improved support of temporal scalability over H.264, by inclusion of the signaling of TemporalId in the NAL unit header. HEVC maintains the NAL unit concept of H.264 with modifications. The RTP packet for H.265/HEVC video <xref target="RFC7798"/> uses a two-byte NAL unit header as shown in <xref target="H265NALUHeader"/>. 
</t>

<t>
The 3 bits field TID specifies the temporal identifier of the NAL unit plus 1.  The value of TemporalId is equal to TID minus 1.  The TID value indicates (among other things) the relative importance of an RTP packet. For example, because NAL units belonging to higher temporal sub-layers are not used for the decoding of lower temporal sub-layers.  A lower value of TID indicates a higher importance. More-important NAL units might need to be better protected against transmission loss or packet dropping than less-important NAL units.
</t>

<figure anchor="H265NALUHeader"><artwork><![CDATA[
              +---------------+---------------+
              |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |F|   Type    |  LayerId  | TID |
              +-------------+-----------------+
         
         The Structure of the HEVC NAL Unit Header.
]]></artwork></figure>
<t>
The type field indicates the different types of RTP packet payload structures. 
</t>
<list style="symbols">
    <t>Single NAL Unit Packet: Contains only a single NAL unit in the payload. The TID field is associated with this single NAL unit.  </t>
    <t> Aggregation Packet (AP): Packet type used to aggregate multiple NAL units into a single RTP payload. A payload header is followed by one or more NAL units in aggregation packets. The value of TID is set as the lowest value of TID of all the aggregated NAL units.</t> 
	<t>Fragmentation Unit (FU): Used to fragment a single NAL unit over multiple RTP packets. Each FU packet has a FU payload header which has the same format as above. The value of the TID field is set according to the value of the TID field in the fragmented NAL unit, which means all the FU packets belong to the same NAL unit have the same TID value.</t> 
	<t>PAyload Content Information (PACI): Used to increase the payload header efficiency. The value of TID is a copy of the TID field of the PACI payload NAL unit or NAL-unit-like structure.</t>   		  
</list>

</section>

<section anchor="H266" title="Packet Level Priority Difference in H.266 RTP Packets">
<t>
Versatile Video Coding (VVC) is formally published as both ITU-T Recommendation H.266 <xref target="VVC"/> and ISO/IEC International Standard 23090-3 <xref target="ISO23090-3"/>.  VVC is reported to provide significant coding efficiency gains over H.265/HEVC, and other earlier video codecs. The RTP payload format for H.266/VVC <xref target="RTP.VVC"/> allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets.
</t>

<t>VVC maintains the NAL unit concept of HEVC with modifications.  VVC uses a two-byte NAL unit header, as shown in <xref target="vvc-nuh"/>.  The payload of a NAL unit refers to the NAL unit excluding the NAL unit header.</t>

<figure anchor="vvc-nuh"><artwork><![CDATA[
              +---------------+---------------+
              |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |F|Z| LayerID   |  Type   | TID |
              +---------------+---------------+

          The Structure of the VVC NAL Unit Header.

]]></artwork></figure>

<t> 
Similar to H.265, the TID value indicates (among other things) the relative importance of an RTP packet, for example, because NAL units belonging to higher temporal sublayers are not used for the decoding of lower temporal sublayers.  A lower value of TID indicates a higher importance. More-important NAL units might need to be better protected against transmission loss or packet dropping than less-important NAL units.
</t>
<t>
The LayerID field is used to identify the layer a NAL unit belongs to, wherein a layer may be, e.g., a spatial scalable layer, a quality scalable layer, a layer containing a different view, etc. The LayerID has integer values, where higher values designate components that are higher in the hierarchy.  Decoding of a particular component requires the availability of all the components it depends upon, either directly, or indirectly. So the NAL unit with lower LayerID would be likely be used to predict the NAL units with higher LayerID, therefore likely to be more important. 
</t>
<t> 
The type field indicates the different types of RTP packet payload structures. 
</t>
<list style="symbols">
    <t>Single NAL Unit Packet: Contains only a single NAL unit in the payload. The TID field is associated with this single NAL unit.  </t>
    <t> Aggregation Packet (AP): Packet type used to aggregate multiple NAL units into a single RTP payload. A payload header is followed by one or more NAL units in aggregation packets. The value of TID is set as the lowest value of TID of all the aggregated NAL units.</t> 
	<t>Fragmentation Unit (FU): Used to fragment a single NAL unit over multiple RTP packets. Each FU packet has a FU payload header which has the same format as above. The value of the TID field is set according to the value of the TID field in the fragmented NAL unit, which means all the FU packets belong to the same NAL unit have the same TID value.</t> 		  
</list>

</section>
</section>

<section anchor="DSCPMapping" title="Implementation of Priority-Based Discarding of RTP Video Packets">
<t> 
Due to the explicit layering in the protocol stack, the upper layer data or headers are transparent to the network layer. The priority or importance associated with the NAL units encapsulated in RTP packets is invisible to intermediate routers. The concept of media-aware network element (MANE) was introduced in <xref target="RFC6184"/>, which is a network element, such as a middlebox or application layer gateway that is capable of parsing certain aspects of the RTP payload headers or the RTP payload and reacting to the contents. The concept of a MANE goes beyond normal routers or gateways in that a MANE has to be aware of the signaling (e.g., to learn about the payload type mappings of the media streams) and that it has to be trusted when working with Secure Real-time Transport Protocol (SRTP) <xref target="RFC3711"/>.  The advantage of using MANEs is that they allow packets to be dropped according to the needs of the media coding.  For example, if a MANE has to drop packets due to congestion on a certain link, it can identify and remove those packets whose elimination produces the least adverse effect on the user experience.
</t>
<t> 
MANEs can access the field that indicates the importance of the NAL unit, which was overviewed in the previous section. In summary:</t>

<t><list style="symbols">
    <t>The two bits NRI field in H.264 and SVC NAL unit header.  </t>
    <t>The 3 bits TID filed in H.265 and H.266 NAL unit header.</t> 
	<t>The 6 bits PRID field in SVC NAL unit extension header, which provides even finer granularity of priority differentiation for NAL units in SVC.</t> 
    <t>The 6 bits LayerID field in H.266 NAL unit payload header, which provides even finer granularity of priority differentiation for NAL units in VVC.</t>  
</list></t>

<t> 
MANE is an overlay network element that might be co-located with a few routers, e.g., at network edge. So when network congestion happens in other routers that is not deployed with MANE, the packet dropping is subject to DiffServ classification  <xref target="RFC2475"/>. DiffServ uses a 6-bit differentiated services code point (DSCP) in the 8-bit differentiated services field (DS field) in the IP header for packet classification purposes. In theory, a network could have up to 64 different traffic classes by using the 64 available DSCP values. However, the commonly defined per-hop behaviors only include 4 categories:
</t> 

<t><list style="symbols">
    <t>Default Forwarding (DF) PHB, which is typically best-effort traffic.  </t>
    <t>Expedited Forwarding (EF) PHB, which is dedicated to low-loss, low-latency traffic.</t> 
	<t>Assured Forwarding (AF) PHB, which gives assurance of delivery under prescribed conditions</t> 
    <t>Class Selector PHBs, which maintain backward compatibility with the IP precedence field.</t> 		  
</list></t>

<t>
We consider the two video types: interactive video and non-interactive video. The video stream from both types could be encoded according to H.264, SVC, H.265, H.266. For H.264 and SVC, the NAL units have the NRI field to indicate the discarding priority of the RTP packets. For H.265 and H.266, the NAL units have the TID field to indicate the discarding priority of the RTP packets. The NRI field is of 2 bits, and the TID field is of 3 bits, thus the DSCP value can be mapped according to either the NRI value or the TID value, as well as the video types. In general, the NAL units with the same NRI value or the TID value in interactive video has higher priority than in non-interactive video. The recommended DSCP values for RTP packets according to NRI value and video type are shown in <xref target="tab-dscp-h264SVC"/>. The recommended DSCP values for RTP packets according to TID value and video type are shown in <xref target="tab-dscp-h265h266"/>.These values are based on the framework and recommended values in <xref target="RFC4594"/>. 
</t>

<table anchor="tab-dscp-h264SVC" align="center" pn="table-1">
        <name>Recommended DSCP Values for RTP Packets According to NRI Value and Video Type (with H.264 or SVC Encoder)</name>
        <thead>
          <tr>
            <th align="center" colspan="1" rowspan="1">NRI Value</th>
            <th align="center" colspan="1" rowspan="1">Interactive Video</th>
            <th align="center" colspan="1" rowspan="1">Non-Interactive Video</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center" colspan="1" rowspan="1">11</td>
            <td align="center" colspan="1" rowspan="1">AF41</td>
            <td align="center" colspan="1" rowspan="1">AF42</td>                       
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">10</td>
            <td align="center" colspan="1" rowspan="1">AF42</td>
            <td align="center" colspan="1" rowspan="1">AF43</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">01</td>
            <td align="center" colspan="1" rowspan="1">AF31</td>
            <td align="center" colspan="1" rowspan="1">AF32</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">00</td>
            <td align="center" colspan="1" rowspan="1">AF32</td>
            <td align="center" colspan="1" rowspan="1">AF33</td>
          </tr>
        </tbody>
</table>
     


<table anchor="tab-dscp-h265h266" align="center" pn="table-2">
        <name>Recommended DSCP Values for RTP Packets According to TID Value and Video Type (with H.265 or H.266 Encoder)</name>
        <thead>
          <tr>
            <th align="center" colspan="1" rowspan="1">TID Value</th>
            <th align="center" colspan="1" rowspan="1">Interactive Video</th>
            <th align="center" colspan="1" rowspan="1">Non-Interactive Video</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center" colspan="1" rowspan="1">001</td>
            <td align="center" colspan="1" rowspan="1">AF41</td>
            <td align="center" colspan="1" rowspan="1">AF42</td>                       
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">010</td>
            <td align="center" colspan="1" rowspan="1">AF42</td>
            <td align="center" colspan="1" rowspan="1">AF43</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">011</td>
            <td align="center" colspan="1" rowspan="1">AF31</td>
            <td align="center" colspan="1" rowspan="1">AF32</td>
          </tr>
          <tr>
            <td align="center" colspan="1" rowspan="1">100</td>
            <td align="center" colspan="1" rowspan="1">AF32</td>
            <td align="center" colspan="1" rowspan="1">AF33</td>
          </tr>
        <tr>
            <td align="center" colspan="1" rowspan="1">101</td>
            <td align="center" colspan="1" rowspan="1">AF21</td>
            <td align="center" colspan="1" rowspan="1">AF22</td>
         </tr>
        <tr>
            <td align="center" colspan="1" rowspan="1">110</td>
            <td align="center" colspan="1" rowspan="1">AF22</td>
            <td align="center" colspan="1" rowspan="1">AF23</td>
         </tr>
        <tr>
            <td align="center" colspan="1" rowspan="1">111</td>
            <td align="center" colspan="1" rowspan="1">AF11</td>
            <td align="center" colspan="1" rowspan="1">AF12</td>
         </tr>         
        </tbody>
</table>

<t>
Either the video host or the MANE at the DiffServ domain edge can do the mapping and set up the DSCP value for each RTP packet. The discarding precedence of the RTP packets can be determined when link congestion happens. 
</t>

<t>
Compared to H.265, SVC and H.266 employ additional scalability other than the temporal scalability, namely spatial scalability and quality scalability. Thus in the NAL extension header for SVC, there is an additional field (i.e., PRID) used to indicate the importance of the RTP packet at finer granularity. The PRID field occupies 6 bits additionally. In the NAL unit header for h.266, the LayerID is used to identify the layer a NAL unit belongs to, wherein a layer may be, e.g., a spatial scalable layer, a quality scalable layer, a layer containing a different view, etc. The LayerID field provides the importance information of the RTP packet at finer granularity as well. The LayerID field occupies 6 bits additionally.
</t>
<t>
It is not feasible to use the DSCP mapping to indicate the additional discarding precedence provided by the 6 bits PRID, and the 6 bits LayerID. Thus, other solutions need to explored in the future if discarding precedence at finer granularity is considered to be supported. 
</t>



</section>

<section title="IANA Considerations">
  <t>
   This document requires no actions from IANA.
 </t>
</section>

<section title="Security Considerations"> 
 <t>
   This document introduces no new security issues.
</t>
</section>

<section title="Acknowledgements">  
</section>

</middle>

  <!-- ***** BACK MATTER ***** -->

  <back>
  
<references title="Informative References">
	<reference anchor="H.264" target="https://www.itu.int/rec/T-REC-H.264-201906-I/en">
      <front>
      <title>
		H.264 : Advanced Video Coding for Generic Audiovisual Services
      </title> 
		<author>
        <organization> ITU-T </organization>
        </author>	  
      <date year="2019" />
      </front>           
    </reference>

<reference anchor="H.265" target="http://handle.itu.int/11.1002/1000/14107">
<front>
    <title>High efficiency video coding, ITU-T Recommendation H.265</title>
    <author >
    <organization></organization>
    </author>
    <date year="2019"/>
</front>
</reference>

<reference anchor="VVC" target="http://www.itu.int/rec/T-REC-H.266">
  <front>
    <title>Versatile Video Coding, ITU-T Recommendation H.266</title>
    <author >
      <organization></organization>
    </author>
    <date year="2020"/>
  </front>
</reference>

<reference anchor="ISO23090-3" target="https://www.iso.org/standard/73022.html">
  <front>
    <title>Information technology - Coded representation of immersive media Part 3 Versatile Video Coding</title>
    <author initials="" surname="ISO/IEC 23090-3" fullname="ISO/IEC 23090-3">
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>



<reference anchor="ISO/IEC14496-10" >
<front>
    <title>ISO/IEC International Standard 14496-10</title>
    <author >
    <organization></organization>
    </author>
    <date year="2015"/>
</front>
</reference>


	
	

	  
	  <reference anchor="RFC2475" target="https://datatracker.ietf.org/doc/html/rfc2475">
      <front>
      <title>
			An Architecture for Differentiated Services
      </title>
      <author  fullname="S. Blake">
      <organization/>
      </author>
	  <author  fullname=" D. Black">
      <organization/>
      </author>
	  <author  fullname=" M. Carlson">
      <organization/>
      </author>
	  <author  fullname=" E. Davies">
      <organization/>
      </author>
	  <author  fullname=" Z. Wang">
      <organization/>
      </author>
	  <author  fullname="W. Weiss">
      <organization/>
      </author>
      <date year="1998" month="December "/>
      </front>
      <seriesInfo name="RFC" value="2475"/>      
      </reference>
	  


	  


<reference anchor='RFC6184' target='https://www.rfc-editor.org/info/rfc6184'>
<front>
<title>RTP Payload Format for H.264 Video</title>
<author fullname='Y.-K. Wang' initials='Y.-K.' surname='Wang'><organization/></author>
<author fullname='R. Even' initials='R.' surname='Even'><organization/></author>
<author fullname='T. Kristensen' initials='T.' surname='Kristensen'><organization/></author>
<author fullname='R. Jesup' initials='R.' surname='Jesup'><organization/></author>
<date month='May' year='2011'/>
</front>
<seriesInfo name='RFC' value='6184'/>
<seriesInfo name='DOI' value='10.17487/RFC6184'/>
</reference>

	  

<reference anchor='RFC6190' target='https://www.rfc-editor.org/info/rfc6190'>
<front>
<title>RTP Payload Format for Scalable Video Coding</title>
<author fullname='S. Wenger' initials='S.' surname='Wenger'><organization/></author>
<author fullname='Y.-K. Wang' initials='Y.-K.' surname='Wang'><organization/></author>
<author fullname='T. Schierl' initials='T.' surname='Schierl'><organization/></author>
<author fullname='A. Eleftheriadis' initials='A.' surname='Eleftheriadis'><organization/></author>
<date month='May' year='2011'/>
</front>
<seriesInfo name='RFC' value='6190'/>
<seriesInfo name='DOI' value='10.17487/RFC6190'/>
</reference>
	  
	


<reference anchor='RFC7798' target='https://www.rfc-editor.org/info/rfc7798'>
<front>
<title>RTP Payload Format for High Efficiency Video Coding (HEVC)</title>
<author fullname='Y.-K. Wang' initials='Y.-K.' surname='Wang'><organization/></author>
<author fullname='Y. Sanchez' initials='Y.' surname='Sanchez'><organization/></author>
<author fullname='T. Schierl' initials='T.' surname='Schierl'><organization/></author>
<author fullname='S. Wenger' initials='S.' surname='Wenger'><organization/></author>
<author fullname='M. M. Hannuksela' initials='M. M.' surname='Hannuksela'><organization/></author>
<date month='March' year='2016'/>
</front>
<seriesInfo name='RFC' value='7798'/>
<seriesInfo name='DOI' value='10.17487/RFC7798'/>
</reference>


<reference anchor="RTP.VVC" target="https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-vvc-14.html">
  <front>
  <title>
  RTP Payload Format for Versatile Video Coding (VVC)
  </title>
  <author  fullname="S. Zhao">
  <organization/>
  </author>
<author  fullname=" D. Black">
  <organization/>
  </author>
<author  fullname=" S. Wnger">
  <organization/>
  </author>
<author  fullname=" Y. Sanchez">
  <organization/>
  </author>
<author  fullname=" Y. Wang">
  <organization/>
  </author> 
  </front>  
</reference>


<reference anchor='RFC3550' target='https://www.rfc-editor.org/info/rfc3550'>
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname='H. Schulzrinne' initials='H.' surname='Schulzrinne'><organization/></author>
<author fullname='S. Casner' initials='S.' surname='Casner'><organization/></author>
<author fullname='R. Frederick' initials='R.' surname='Frederick'><organization/></author>
<author fullname='V. Jacobson' initials='V.' surname='Jacobson'><organization/></author>
<date month='July' year='2003'/>
</front>
<seriesInfo name='STD' value='64'/>
<seriesInfo name='RFC' value='3550'/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/>
</reference>
	


<reference anchor='RFC3711' target='https://www.rfc-editor.org/info/rfc3711'>
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author fullname='M. Baugher' initials='M.' surname='Baugher'><organization/></author>
<author fullname='D. McGrew' initials='D.' surname='McGrew'><organization/></author>
<author fullname='M. Naslund' initials='M.' surname='Naslund'><organization/></author>
<author fullname='E. Carrara' initials='E.' surname='Carrara'><organization/></author>
<author fullname='K. Norrman' initials='K.' surname='Norrman'><organization/></author>
<date month='March' year='2004'/>
</front>
<seriesInfo name='RFC' value='3711'/>
<seriesInfo name='DOI' value='10.17487/RFC3711'/>
</reference>


<reference anchor='RFC4594' target='https://www.rfc-editor.org/info/rfc4594'>
<front>
<title>TConfiguration Guidelines for DiffServ Service Classes</title>
<author fullname='J. Babiarz' ><organization/></author>
<author fullname='K. Chan'><organization/></author>
<author fullname='F. Baker' ><organization/></author>
<date month='August' year='2006'/>
</front>
<seriesInfo name='RFC' value='4594'/>
<seriesInfo name='DOI' value='10.17487/RFC4594'/>
</reference>

	
</references>

  </back>
</rfc>
