[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-ipmulticast-ipdvb-awa-01.txt

To: "'ipdvb@erg.abdn.ac.uk'" <ipdvb@erg.abdn.ac.uk>, internet-drafts@ietf.org
Subject: draft-ipmulticast-ipdvb-awa-01.txt
From: "Allison, Art" <AAllison@nab.org>
Date: Wed, 14 Jul 2004 14:57:29 -0400
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-to: ipdvb@erg.abdn.ac.uk
Sender: owner-ipdvb@erg.abdn.ac.uk

Please find attached the draft-ipmulticast-ipdvb-awa-01.txt as an individual submission to be discussed further at the will of those participating in ipdvb WG meeting at IETF 60.

Arthur W. Allison

Delivery of IP Multicast Sessions Using ISO/IEC 13818-1:2000
1. SCOPE
This standard specifies the delivery of IP Multicast sessions, and the delivery of data for describing the characteristics of a session for IP Multicast.
This document defines a Standard for the asynchronous transmission of Internet Protocols (IP) specifically it is compatible with the ATSC A/90 Data Broadcast Standard. This Standard assumes the use of Session Description Protocol (SDP) as an integral part of the IP Multicast-based Data Broadcast service. It is strongly suggested that normative clauses that do not directly involve SDP be retained in the case of IP Multicast-based Data Broadcast services that do not include any SDP data, such as would be used for non-session-based IP Multicast.
This document focuses solely on the carriage of all information using the DSMCC_addressable_section. Synchronous and synchronized carriage of IP Multicast datagrams are not addressed by this document.

1.1. Organization
Entire normative sections of this document are identified as such with the parenthetical "(Normative)". Other sections may contain normative clauses that are identified by use of the preamble "Normative Clause" and by distinctive formatting of the normative clause. All remaining text is provided for informational purposes only.
The document is organized as follows:
Section 1-Provides this general introduction.
Section 2-Lists references and applicable documents.
Section 3-Provides a definition of terms, acronyms, abbreviations, syntax formats, and code points for this document.
Section 4-Specifies the IP Network model in an ATSC Transport Stream.
Section 5-Specifies the rules for mapping IP Multicast sessions to ATSC Virtual Channels.
Section 6-Specifies usage of the Session Description Protocol.
Section 7-Specifies the encapsulation for IP Multicast datagrams.
Section 8-Specifies the schedule announcement of an IP Multicast data service.
Section 9-Specifies the receiver discovery and binding mechanisms for an IP Multicast service.
Section 10-Illustrates the application buffer model of an IP Multicast service.
Section 11-Describes options for the scrambling of IP Multicast streams.
Section 12-Provides an overview for how an IP Multicast service may be acquired.
Section 13-Describes the use of the Network Resources Table.
Section 14-Describes the IP Multicast application buffer model.
Section 15-Provides the syntax and semantics of the MAC_Address_List_descriptor.

2. REFERENCES
2.1 Normative References (Normative)
The following documents are normative for this Standard:
1) ATSC A/90, "ATSC Data Broadcast Standard," July 26, 2000.
2) ATSC A/65A, "Program and System Information Protocol for Terrestrial Broadcast and Cable," May 31, 2000.
3) IETF RFC 2327, "SDP: Session Description Protocol," April 1998.
4) IETF RFC 1112, "Host Extensions for IP Multicasting," August 1989.
5) IETF RFC 1700, "Assigned Numbers," October 1994.
6) IETF RFC 2974, "Session Announcement Protocol," October 2000.

2.2 Informative References
The following documents are informative for this Standard:
7) ATSC A/70, "Conditional Access System for Terrestrial Broadcast and Amendment No. 1," July 17, 1999.
8) SMPTE 357M, "Declarative Data Essence, IP Multicast Encapsulation."
9) IETF RFC 2365, "Administratively Scoped IP Multicast," July 1998.
10) ISO/IEC 13818-6:1998/Amd.1:2000(E) - "Additions to support data broadcasting."
11) SCTE DVS 311r6, "IP Multicast for Digital MPEG Networks," March 2002.

3. DEFINITIONS AND STRUCTURES (NORMATIVE)

3.1 Compliance Notation
As used in this document, "shall" denotes a mandatory provision of the standard. "Should" denotes a provision that is recommended but not mandatory. "May" denotes a feature whose presence does not preclude compliance, that may or may not be present at the option of the implementer.
All sections of this document are informative, unless otherwise specifically indicated with the heading "Normative Clause" or which contain the word "Normative" in parenthesis in the section title.

3.2 Acronyms and Abbreviations
The following acronyms and abbreviations are used within this specification:
ATSC Advanced Television Systems Committee
bslbf bit serial, leftmost bit first
CRC cyclic redundancy check
DDE declarative data essence
DEB data program element buffer
DET data event table
DSM-CC digital storage media command and control
DST data service table
EIT event information table
ETM extended text message
ETT extended text table
FRAGnkj IP fragmentation buffer for fragment identifier j, multicast address k, in program element n.
IETF Internet Engineering Task Force
IP Internet Protocol
IPM IP Multicast
IPGRMBnk IP datagram buffer for kth IP Multicast address in the nth program element
ITU International Telecommunication Union
MAC media access control
MPE multi-protocol encapsulation
MPEG Moving Picture Experts Group
MTU maximum transmission unit
MS media stream
NRT network resources table
NTP network time protocol
PAT program association table
PDU protocol data unit
PES packetized elementary stream
PID packet identifier
PMT program map table
PSIP program and system information protocol
RFC request for comments
SAP session announcement protocol
SBn smoothing buffer for the nth program element
SCTE Society of Cable Telecommunications Engineers
SDP session description protocol
SDF service description framework
SLD service location descriptor
SMPTE Society of Motion Picture and Television Engineers
TBn transport buffer for the nth program element
TS transport stream
TTL time to live
uimsbf unsigned integer, most significant bit first
nbomsbf network byte order, most significant bit first
UDP user datagram protocol
UDPnkji UDP buffer for port i, fragment identifier j, IP multicast address k, in program element n.
VCT virtual channel table

3.3 Global Terms
The following terms are used throughout this document:
ATSC Advanced Television Systems Committee. The committee responsible for the coordination and development of voluntary technical standards for advanced television systems.
bit rate The rate at which the compressed bit stream is delivered from the channel to the input of a decoder.
bps bits per second.
byte-aligned A bit in a coded bit stream is byte-aligned if its position is a multiple of 8-bits from the first bit in the stream.
CRC The cyclic redundancy check used to verify the correctness of the data.
data element A self-contained subset of a data Program Element.
data receiver Any device capable of receiving and consuming data carried on an MPEG-2 transport stream.
data service A collection of scheduled applications and associated data Program Elements as signaled in one Data Services Table. A data service is characterized by a profile and level.
datagram A datagram is the fundamental protocol data unit in a packet-oriented data delivery protocol. Typically, a datagram is divided into header and data areas, where the header contains full addressing information (source and destination IP addresses) with each data unit. Datagrams are most often associated with connectionless network and transport layer services.
data source The provider of data that is being inserted into the MPEG-2 transport stream.
decoded stream The decoded reconstruction of a compressed bit stream.
decoder An embodiment of a decoding process.
decoding (process) The process defined in the Digital Television Standard that reads an input coded bit stream and outputs decoded pictures, audio samples, or data objects.
elementary stream (ES) A generic term for one of the coded video or coded audio bit streams. One elementary stream is carried in a sequence of PES packets with one and only one stream_id.
encoding (process) A process that reads a stream of input pictures or audio samples and produces a valid coded bit stream as defined in the Digital Television Standard.
event A collection of elementary streams with a common time base, an associated start time, and an associated end time. An event is equivalent to the common industry usage of "TV program."
forbidden This term, when used in clauses defining the coded bit stream, indicates that the value shall never be used. This is usually to avoid emulation of start codes.
IP multicast application buffer The buffer following the Smoothing Buffer of an MPEG-2 Program Element of stream_type 0x0D as defined in [1]. The purpose of this buffer is to collect only the IP Multicast data bytes out of the Smoothing Buffer and to re-assemble them into complete datagrams.
IP multicast data stream A collection of IP packets with the same IP Multicast address and port number.
IPM program element An MPEG-2 Program Element of stream_type 0x0D that carries IP Multicast datagrams in DSM-CC addressable sections.
IP multicast service The portion of an A/90 Data Broadcast service comprising the IP Multicast sessions and their announcements and descriptions.
IP multicast virtual channel An ATSC virtual channel including an IP Multicast service. The virtual channel may include other video and audio elementary streams.
kbps 1,000 bits per second.
maximum transmission unit The largest amount of data that can be transferred in a single unit across a specific physical connection. When using the Internet Protocol, this translates to the largest IP datagram size allowed.
Mbps 1,000,000 bits per second.
MPEG Refers to standards developed by the ISO/IEC JTC1/SC29 WG11, Moving Picture Experts Group. MPEG may also refer to the Group.
MPEG-2 Refers to the collection of ISO/IEC standards 13818-1 through 13818-6.
multiplexor (mux) A physical device that is capable of inserting MPEG-2 transport stream packets into and extracting MPEG-2 transport stream packets from an MPEG-2 transport stream.
multiprotocol encapsulation The encapsulation or splitting of datagrams in addressable sections.
packet A packet is a set of contiguous bytes consisting of a header followed by its payload.
packet identifier (PID) A unique integer value used to associate Program Elements of a program in a single or multi-program transport stream.
payload Payload refers to the bytes following the header byte in a packet.
program A collection of Program Elements. Program Elements may be elementary streams. Program Elements need not have any defined time base; those that do have a common time base and are intended for synchronized presentation. The term program is also used in the context of a "television program" such as a scheduled daily news broadcast. In this specification the term "event" is used for the latter to avoid ambiguity.
program element A generic term for one of the elementary streams or other data streams that may be included in an ISO/IEC 13818-1 (MPEG-2) Program. The MPEG-2 Transport Stream packets conveying a Program Element are referenced by a unique PID value in the MPEG-2 Program.
program specific information (PSI) PSI consists of normative data which is necessary for the demultiplexing of transport streams and the successful regeneration of programs.
profile A defined subset of data delivery characteristics. This differs from the definition provided in ISO/IEC 13818-2.
PSIP Program and System Information Protocol is a collection of tables describing virtual channel attributes, event features, and other information [2].
reserved This term, when used in clauses defining the coded bit stream, indicates that the field may be used in the future for Digital Television Standard extensions. All reserved bits shall be set to "1".
SDP announcement stream A collection of Session Description Protocol datagrams transmitted on a given IP Multicast address and pertaining to the same sessionID.
SDP stream The collection of one or more SDP announcement streams.
section A data structure comprising a portion of an ISO/IEC 13818-1 or ISO/IEC 13818-6-defined table, such as the Program Association Table (PAT), Conditional Access Table (CAT), Program Map Table (PMT), or DSMCC section. All sections begin with the table_id and end with the CRC_32 field, and their starting points within a packet payload are indicated by the pointer_field mechanism defined in the ISO/IEC 13818-1 International Standard.
service description framework The information conveyed in the Program Element and providing the Data Service Table and optionally the Network Resource Table of a single data service.
session A collection of IP Multicast data streams bound by a common announcement and description. Announcement and description protocols are defined in IETF RFC 2974 and IETF RFC 2327 respectively.
session announcement This term is defined explicitly in RFC2327 and reproduced here for convenience. A session announcement is a mechanism by which a session description is conveyed to users in a proactive fashion, i.e., the session description was not explicitly requested by the user.
session description Information used to announce and discover a session, which may include session identification, session version, name, start and end times, and other information.
stream An ordered series of bytes. The usual context for the term stream is the series of bytes extracted from Transport Stream packet payloads which have a common unique PID value (e.g., video PES packets or Program Map Table sections).
stream data A stream is a data object which has no specific start or end. The decoding system may need only a small fraction of the total data to activate a given application. An example includes stock ticker services.
table The collection of re-assembled sections bearing a common version number.
table instance Tables are identified by the table_id field. However, in cases such as the Data Information Table, several instances of a table are defined simultaneously. All instances have the same PID and table_id but different table_id_extension.
transport stream Refers to the MPEG-2 Transport Stream syntax for the packetization and multiplexing of video, audio, and data signals for digital broadcast systems.
transport stream packet header The leading fields in a Transport Stream packet up to and including the continuity_counter field.
virtual channel A virtual channel is the designation, usually a number, that is recognized by the user as the single entity that will provide access to an analog TV program or a set of one or more digital elementary streams. It is called "virtual" because its identification (name and number) may be defined independently from its physical location.

3.4 Section and Data Structure Syntax Notation
Tables defined in this standard conform to the generic private section syntax defined in ISO/IEC 13818-1 (MPEG-2 Systems) and the DSM-CC Addressable section format defined in [10]. This document contains symbolic references to syntactic elements. The notation used is distinctive to aid the reader in recognizing elements that are the same as they are in referenced standards. These references are typographically distinguished by the use of a different font (e.g., restricted), may contain the underscore character (e.g., sequence_end_code) and may consist of character strings that are not English words (e.g., dynrng or thisIsString).
reserved-Fields in this Standard marked "reserved" shall not be assigned by the user, but shall be available for future use. Decoders are expected to disregard reserved fields for which no definition exists. Each bit in the fields marked "reserved" shall be set to one until such time as they are defined and supported.
user_private-Indicates that the field is not defined within the scope of this Standard. The owner of the field, and hence the entity defining its meaning, is derived via its context within a message.
zero-Indicates that the bit or bit field shall have the value zero.

4. MPEG TRANSPORT IP NETWORK MODEL
The purpose of this section is to define a model whereby standard IP network terminology and concepts can be applied to transmission of IP Multicast services in an ATSC Transport Stream. When creating, inserting, and transporting IP packets through an ATSC Transport Stream, rules need to be established to define what constitutes a network or sub-network. This is critical for all implementations, as there is the strong potential for IP address conflicts without such rules.

4.1 Mapping of an IP Network
Normative Clause
In an ATSC Transport Stream, the collection of Program Elements referenced in a single ATSC A/90 Application shall be considered as a distinct IP Network. More specifically, when making routing policies and IP address scoping policies, it is the collection of Taps in an ATSC A/90 Application that shall be viewed as the Network.
Consequently, in a given ATSC A/90 Application, a receiver can safely assume that there is no collision among the IP Multicast addresses encountered in the IP datagram headers.
Since an ATSC A/90 Application may reference one or multiple MPEG-2 Program Elements of stream_type 0x0D, the mapping of an IP Network onto an ATSC A/90 Application may be done such that the streams of an IP Multicast service may all be conveyed in either a single or multiple Program Elements. In one extreme case, the entire IP Multicast service is conveyed in one Program Element, and this single Program Element alone makes up the IP Network. In another extreme case, the IP Multicast service is divided up among multiple Program Elements that are all part of the same ATSC A/90 Application, and then this collection of Program Elements makes up the IP Network.

4.2 Mapping of Sessions
The purpose of this section is to document various cases that may be encountered when an ATSC Virtual Channel includes one or more IP Multicast sessions. For the sake of simplicity, the documented examples involve two distinct IP Multicast sessions only. The concepts documented in this section can be quickly generalized to cases involving more sessions and more media streams.
Normative Clause
An IP Multicast session shall be announced by means of the Session Description Protocol (SDP) [3)]. The Session Announcement Protocol (SAP) [6] shall be used to encapsulate the SDP protocol in UDP datagrams.

4.2.1 Notations
The following notation is used to reference particular IP Multicast streams. The terms defined here refer to two distinct sessions, Session 1 and Session 2. Each session is assumed to have a distinct sessionID field value in the typical case, but there are some circumstances where this may not be true. Furthermore, the term "IP Multicast address" refers to the Internet Protocol address and port as specified in the destination address field of the IP packet header and UDP datagram header respectively.
SDP1 and SDP2: Session Description Protocol streams of session 1 and 2, respectively. The IP Multicast address for SDP1 and SDP2 may be identical, but the sessionID field values are not.
MS11 and MS12: IP Multicast Media stream 1 and IP Multicast Media stream 2 for session 1.
MS21 and MS22: IP Multicast Media stream 1 and IP Multicast Media stream 2 for session 2.
PID1 through PID6: PID values associated to six different Program Elements of stream_type 0x0D.

4.2.2 Mapping Scenarios
The following 8 scenarios are examples of various strategies that may be adopted for transmitting an IP Multicast service in an ATSC Virtual Channel. Each scenario documents how two distinct SDP sessions can be conveyed in an ATSC virtual channel. Each scenario utilizes a certain number of MPEG-2 Program Elements. Selection of one scenario over another may be driven by the need to improve session discovery, by latency considerations, bandwidth allocation, insertion point in the distribution, or by other implementation factors.
Case 1
PID1 conveys SDP1 MS11 MS12 SDP2 MS21 MS22
In this case, one Program Element conveys all the IP Multicast datagrams. By design, the Program Element referenced by PID1 is part of a single ATSC A/90 Application and the IP Network is confined to a single Program Element.
Case 2
PID1 conveys SDP1 MS11 MS12
PID2 conveys SDP2 MS21 MS22
In this case, each IP Multicast session is conveyed in a distinct Program Element. The sessions may be part of the same ATSC A/90 Application or they may each belong to a separate ATSC A/90 Application. In the latter scenario, each Program Element represents a distinct IP Network.
Case 3
PID1 conveys SDP1
PID2 conveys MS11 MS12
PID3 conveys SDP2
PID4 conveys MS21 MS22
In this case, Program Elements referenced by PID1 and PID2 carry datagrams of the same IP Multicast session and therefore they need to belong to the same ATSC A/90 Application. For the same reason PID3 and PID4 must belong to the same application. With these constraints, the two alternatives for encapsulation include: 1) setting up a single application with both sessions included, or 2) setting up two separate applications one for each session. Depending on the selected alternative, the result will be either one or two IP networks respectively.
Case 4
PID1 conveys SDP1 SDP2
PID2 conveys MS11 MS12
PID3 conveys MS21 MS22
In this case, one Program Element (referenced by PID1) conveys the datagrams of all the IP Multicast announcement streams. By design, the Program Element PID1 and the Program Elements PID2 and PID3 must belong to a single ATSC A/90 Application.
Case 5
PID1 conveys SDP1 SDP2
PID2 conveys MS11 MS12 MS21 MS22
In this case, one Program Element conveys the datagrams of all the IP Multicast announcement streams. The other Program Element conveys the datagrams of all the IP Multicast Media streams. By design, the Program Element PID1 and the Program Elements PID2 must belong to a single ATSC A/90 Application, thus resulting in a single IP network where no IP address collisions exist.
Case 6
PID1 conveys SDP1
PID2 conveys MS11
PID3 conveys MS12
PID4 conveys SDP2
PID5 conveys MS21
PID6 conveys MS22
Program Elements referenced by PID1, PID2 and PID3 must belong to the same ATSC A/90 Application, and similarly for PID4, PID5, and PID6. Two implementation alternatives exist in this case. Either the two sessions are included in only one application, or two separate ATSC A/90 applications are used. Depending on the selected alternative, the result will be one or two IP networks respectively.
Case 7
PID1 conveys SDP1 SDP2
PID2 conveys MS11
PID3 conveys MS12
PID4 conveys MS21
PID5 conveys MS22
In this case, one Program Element conveys the datagrams of all the IP Multicast announcement streams. By design, the Program Element referenced by PID1 and the Program Elements referenced by PID2, PID3, PID4, and PID5 must belong to a single ATSC A/90 Application.
Case 8
PID1 conveys SDP1
PID2 conveys SDP2
PID3 conveys MS11 MS12 MS21 MS22
In this case, the IP Multicast session description streams are conveyed in distinct Program Elements and the IP Multicast Media streams pertaining to all sessions are conveyed in the same Program Element. In this case both sessions must belong to the same ATSC A/90 Application, thus resulting in a single IP network where IP address collisions do not exist.

4.2.3 Identification of the Broadcast IP Network in Data Receivers
Normative Clause
The value of the DST app_id_length field shall be 2 or greater. The meaning of the DST app_id_description field shall be as specified in ATSC A/90 [1)], and the value shall be set to 0x0002. The app_id_description and app_id_bytes fields shall uniquely identify the ATSC A/90 Application globally in space and time. When app_id_description is set to 0x0002, the app_id_bytes shall be set to the binary representation of the NTP time stamp as recommended in [3] for sessionID.
As a result, receivers can use the app_id_description and app_id_bytes fields of an ATSC A/90 Application to identify uniquely the IP network associated with this application. More specifically, a receiver may use these fields to assign and manage the local IP address of the Broadcast Network Interface (single network adaptor) that gets associated with each ATSC A/90 Application. Multiple applications define multiple networks resulting in a multi-home scenario.
Note that the app_id_byte field may be set to the value of the sessionId field used in an IP Multicast Service SDP record.

5. MAPPING OF IP MULTICAST SESSIONS TO PROGRAM ELEMENTS AND VIRTUAL CHANNELS
Mapping of one or multiple IP Multicast sessions onto an ATSC Transport Stream needs to take several factors into consideration.
The first consideration is the mapping of the IP Multicast sessions to one or multiple ATSC A/90 Applications. Different criteria are listed to guide content providers in identifying the best method. The second consideration deals with the announcement of the IP Multicast session announcement. This consideration allows content providers to decide whether one or multiple ATSC Virtual Channels should be used.

5.1 Mapping to ATSC A/90 Applications

5.1.1 Multiple Sessions in the Same Application
The insertion of multiple sessions in the same application (at either one or multiple entry points in the distribution chain) requires careful management to avoid IP address collisions if these sessions overlap in time. The management functions may be performed through cooperative authoring or instead, they may be applied in real time using IP address re-mapping.
The IP Multicast specifications for cable require having one IP network per virtual channel [11]. Consequently, if compatibility becomes a desired design premise, then all sessions can be embedded in a single application. Moreover, this application can be the only IP Multicast application in the MPEG-2 Program.
In one extreme case, all sessions may be embedded in a single Program Element as a method to reduce the number of PID filters required in a receiver. In the other extreme case, every session announcement (SDP) and every media stream are conveyed over separate Program Elements. The advantage of the latter is that once the required session is discovered, selective retrieval of media streams may be performed by direct PID filtering.
Receivers that detect IP Multicast streams may have to parse the associated streams in search of all possible SDP announcements. Notice that the signaling in the DST may not give enough information on how many sessions are running concurrently. Receivers that know a-priori the IP address of the particular multicast sessions of interest will use the MAC Address List descriptor and the Tap selector structures in the DST to pinpoint the collection of PID values to use for the PID filters.

5.1.2 Multiple Insertion Points
When sessions are inserted in multiple entry points of the distribution chain, IP address management may become a burden. In such a case, the inserted IP Multicast sessions may be mapped to different applications in the same virtual channel. Cases 2, 3, and 6, described in the previous section, are typical examples of this behavior.

5.1.3 Conditional Access Granularity
The ATSC Conditional Access standard [7] describes a method to scramble one or more Program Elements in an MPEG-2 Program. Scrambling is performed at the Transport level, which essentially means that the payload of the 188-byte length packets gets encrypted. If there are several IP Multicast sessions sharing one Program Element (defined by one PID value), then all the sessions will be scrambled if A/70 is used. For DSM-CC Addressable Sections, ATSC A/90 offers Section-level scrambling, however, the use of this function has not been standardized. More details on Section-level scrambling are described in Section 11 of this document.
Transport-level scrambling can be used in conjunction with the appropriate application design to enable authors to perform selective scrambling of sessions and/or data components. For instance, if one were to implement the example defined as Case 4 (see previous section), then it would be possible to scramble the content of session 2 independently of session 1. Case 6 is the case where each IP Multicast stream of a session is carried in a single Program Element and therefore each IP Multicast media stream may be encrypted independently. Case 8 provides the opportunity for applying conditional access collectively to the IP Multicast media streams while leaving all session description datagrams in the clear (non-encrypted).

5.2 Mapping to ATSC Virtual Channels

5.2.1 Multiple Sessions in the Same Virtual Channel
Cases 2, 3, or 6 allow use of one or multiple ATSC A/90 Applications in the Virtual Channel containing the IP Multicast service. The fact that such IP Multicast sessions reside in the same ATSC A/90 Application means that they have been authored so their IP Multicast addresses do not conflict. However, possibility for multiple insertion points may be a driving consideration to use several ATSC A/90 Applications in the same virtual channel. In both cases, the IP Multicast sessions and their instances are selected based on an application-level selection mechanism that uses the information provided in the SDP datagrams. Due to limitations in current receivers, it may be desirable to limit only one A/90 application per Virtual Channel if it is desired to run multiple IP Multicast sessions in the receiver.

5.2.2 Multiple Sessions and Multiple Virtual Channels
When it is desired to provide a distinct announcement in the EIT or DET of the schedule for each IP Multicast session, or when it is desired to allow a PSIP-based selection of an IP Multicast session, the ATSC A/90 Application referencing the Program Elements carrying the IP Multicast session stream can belong to a distinct PSIP Virtual Channel. In this situation, whether Case 2, 3, or 6 is used, the Program Elements conveying the IP Multicast session stream belongs not only to a distinct ATSC A/90 Application but also to a distinct ATSC Virtual Channel.
The previous sections described recommendations and suggestions to consider when mapping IP Multicast sessions into one or more applications. However, when multiple applications exist concurrently, it becomes possible to insert some of them in a different virtual channel. Applications need to be inserted in a different virtual channel mainly for two reasons: compatibility with cable [11], and the need to separately announce or signal applications in PSIP [2)].

6. SDP USAGE CONSIDERATIONS
Normative Clause
The creation of the sessionID field values shall be such that the values are guaranteed at least not to collide with the sessionID field values of other sessions belonging to the same ATSC A/90 Application.
In order for authoring tools to ensure uniqueness of the sessionID values, they should be created as recommended in the SDP specification and use a hexadecimal representation of NTP time.
Normative Clause
The sum of the leak rates specified in all the SDP Session Descriptions (as specified by the b=CT:number entry) of a Data Service shall not exceed the leak rate specified by the sb_leak parameter associated with the data_service_profile field in the data_service_descriptor or by the sb_leak_rate field in the smoothing_buffer_descriptor associated with the ATSC Virtual Channel or the sum of the sb_leak_rate field(s) in the smoothing_buffer_descriptor(s) of the MPEG-2 Program Element(s) carrying the IP datagrams of the session. The bandwidth signaling shall be consistent between the SDP records, the A/90 descriptors, and the MPEG-2 descriptors.

7. DATAGRAM ENCAPSULATION

7.1 Introduction
IP Multicast datagrams are UDP/IP datagrams for which the IP destination address is in the range 224.0.0.0 to 239.255.255 as defined in [9]. Each datagram is encapsulated in DSMCC_Addressable_section structures as defined by [10].

7.2 Protocol Encapsulation
Normative Clause
Individual IP Multicast datagrams shall be conveyed by means of ATSC A/90 DSMCC_addressable_section structures. The corresponding ATSC A/90 protocol_encapsulation field value in the ATSC A/90 Data Service Table (DST) shall be set to 0x04. All DSMCC_addressable_section structures conveying the IP Multicast datagrams of an IP Multicast service shall be transmitted in one or more MPEG-2 Program Elements. The stream_type value associated with these Program Elements shall be equal to 0x0D.

7.3 DSM-CC Addressable sections
Normative Clause
When a DSM-CC Addressable section conveys an IP Multicast datagram with unscrambled deviceId fields, the deviceId[47...40], deviceId[39...32], and deviceId[31...24] fields shall be equal to 0x01, 0x00, and 0x5E, respectively as specified in [4]. Furthermore, the deviceId[23] bit shall always be set to '0' as specified in [10]. The LLCSNAP_flag field shall be set to '0' and the maximum transmission unit (MTU) of the IP datagrams shall be 4080 bytes.

7.4 Format of Device Identifier Fields
The format of the deviceId fields in the DSMCC_Addressable_section structures referenced by a Tap may be specified by the insertion of a multiprotocol_encapsulation_descriptor in the descriptor loop of that Tap.
Normative Clause
When the descriptor loop of an ATSC A/90 Tap referencing an MPEG-2 Program Element of protocol_encapsulation value 0x04 does not include a multiprotocol_encapsulation_descriptor structure, the default deviceId_address_range field value shall be 0x06 meaning that all 48 bits are valid. The default deviceId_IP_mapping_flag value shall be equal to '1' to indicate an IP to MAC address mapping according to RFC 1112 [4]. The default max_sections_per_datagram field value shall be equal to 0x01.
When a descriptor loop of an ATSC A/90 Tap referencing an MPEG-2 Program Element of protocol_encapsulation value 0x04 does not include a multiprotocol_encapsulation_descriptor structure, the value of the deviceId_IP_mapping_flag field shall always be equal to '1' to indicate an IP to MAC address mapping according to RFC1112 [4]. The value of the max_sections_per_datagram field shall always be equal to 0x01.
The deviceId and MAC Address are interchangeable terms.

8. SERVICE ANNOUNCEMENT AND SCHEDULE

8.1 Introduction
A stand-alone IP Multicast service is a data service not related to any audio-visual event. The IP Multicast service may include one or several IP Multicast sessions. If the service includes multiple sessions, one or several ATSC A/90 Applications may be used to signal the sessions. The schedule of a standalone IP Multicast service is announced by means of instances of ATSC Data Event Tables (DET-k's). In this case, the value of the service_type field associated with the Virtual Channel in the PSIP Virtual Channel Table (VCT) is equal to 0x04. The one or more data Program Elements conveying the stand-alone IP Multicast service belong to a single and distinct ATSC Virtual Channel. Consequently, the PSIP Service Location Descriptor associated with the stand-alone IP Multicast service virtual channel does not include any Program Element of type 0x02 (MPEG-2 video) or 0x81 (AC-3 audio).
The schedule of a single IP Multicast service related to one or several audio-visual events is announced by means of instances of ATSC Event Information Tables (EIT-k's) or Data Event Tables (DET-k's). Scenarios for using DET-k tables versus EIT-k tables are documented in the ATSC A/90 specification. The IP Multicast service may include one or several IP Multicast sessions. If the service includes multiple sessions, one or several ATSC A/90 Applications may be used to signal the sessions. The value of the service_type field associated with the Virtual Channel in the PSIP Virtual Channel Table is equal to 0x02 if the Virtual Channel includes a video elementary stream of stream_type 0x02. It is equal to 0x03 if the Virtual Channel includes an audio elementary stream of stream_type 0x81 but no video elementary stream of stream_type 0x02. The one or more data Program Element(s) of an IP Multicast service belong to the same virtual channel as the video and/or audio elementary streams.
In both cases, the IPM Program Elements are listed in the Service Location Descriptor associated in the VCT with the ATSC Virtual Channel to which the IP Multicast service belongs. The ATSC Virtual Channel also includes one and only one MPEG-2 Program Element of stream_type 0x95 which is used to convey Service Description Framework information as specified in ATSC A/90 and further enhanced with the constraints and rules specified herein.
The announcement of the schedule of any IP Multicast service complies with the ATSC A/65A specification. The schedule of any IP Multicast service is published by means of Event Information Tables (EIT-k's) or Data Event Tables (DET-k's).
In the case of IP Multicast services related to one or multiple audio-visual events (service_type 0x02 or 0x03 as appropriate), the schedule (start time, duration) of the IP Multicast sessions may or may not coincide with the schedule of the associated audio-visual event.

8.2 Data Event Table (DET)
DET-k's are used for announcing the event schedule of a stand-alone IP Multicast service in an ATSC Virtual Channel. As specified in the ATSC A/90 specification, DET-k's may also be used for announcing an event of an IP Multicast service provided in an ATSC Virtual Channel that also includes a video and/or audio event. In the latter case, both an EIT and DET are used, the EIT to announce the video and/or audio event(s), and the DET to announce the IP Multicast event(s).

8.3 Data Service Descriptor
As required by the ATSC A/90 specification, the descriptor loop associated with the IP Multicast service event in a DET-k or an EIT-k includes a data_service_descriptor structure. The value of the data_service_profile field in this descriptor is set to indicate the proper upper bandwidth bound used for the delivery of the IP Multicast service.
Normative Clause:
The value of the data_service_level field shall be set to 0x00 to indicate that the IP Multicast service is an asynchronous service.

8.4 PID Count Descriptor
The descriptor loop associated with the IP Multicast data broadcast event listed in a DET-k or an EIT-k may include a PID_count_descriptor structure [1]. The value of the total_number_of_PIDs field accounts for all the IPM Program Elements in the virtual channel. When the IP Multicast media stream(s) and the SDP datagram stream(s) are conveyed in the same MPEG-2 Program Element, the value of the min_number_of_PIDs field is equal to 0x02 to indicate that a meaningful rendition of the IP Multicast service can be obtained from only one data Program Element and the Program Element conveying the Data Service Table. When the IP Multicast media stream(s) and the SDP datagram stream(s) are conveyed in distinct MPEG-2 Program Elements, the value of min_number_of_PIDs field is equal to 0x03 to indicate that a meaningful rendition of the IP Multicast service can be obtained from two data Program Elements (one conveying the SDP datagrams and the other the media datagrams) and the Program Element conveying the Data Service Table.

9. SIGNALING FOR DISCOVERY AND BINDING OF AN IP MULTICAST SERVICE

9.1 Introduction
This specification defines a variety of ways for signaling an IP Multicast service within the Service Description Framework defined by the ATSC A/90 Specification. In this section, detailed usage recommendations are provided for each scenario. More specifically, the scenarios that are discussed are the following:
1) A single IP Multicast session on a single ATSC Virtual Channel
2) Multiple IP Multicast sessions on a single ATSC Virtual Channel
3) Multiple IP Multicast sessions on multiple ATSC Virtual Channels
Signaling information is used by the IP Multicast receiver to discover the IP Multicast service and to bind the various IP Multicast media and SDP announcement streams to particular MPEG-2 Program Elements. An additional structure that may be used in the ATSC A/90 Data Service Table is the MAC_Address_List_descriptor. This descriptor is discussed in the following section.

9.2 THE MAC Address List Descriptor

9.2.1 Definition
The MAC_Address_List_descriptor structure is defined in Section 18. This descriptor was originally defined by SCTE [11]. The MAC_Address_List_Descriptor may be used in the Data Service Table to list the MAC Layer Multicast addresses used in the ATSC Virtual Channel.

9.2.2 Use of this Descriptor in the Data Service Table (DST)
Normative Clause
The use of the MAC Address List descriptor is optional in the DST of a Virtual Channel conveying an IP Multicast service. The MAC_Address_List_descriptor may be located in the descriptor loop of a Tap referencing a Program Element of stream_type 0x0D and conveying IP Multicast datagrams encapsulated in DSMCC_Addressable_section structures. If the descriptor is used, both the value of the pdu_size field and the encapsulation_type field of the MAC_Address_List_descriptor structure shall always be equal to '11'.
The purpose of the MAC_Address_List_descriptor is to list MAC layer Multicast addresses present in a given MPEG-2 Program Element. A data receiver may elect to use the information provided by this descriptor to identify the Program Elements that need to be latched and acquired. The information provided in the descriptor is especially helpful if the IP Multicast service includes multiple sessions in the same A/90 Application or in the same Virtual Channel.
Normative Clause
In the case of an ATSC A/90 Application including an IP Multicast service, and if the MAC_Address_List_descriptor is used in this ATSC A/90 Application, the union set of all the MAC_Address_List_descriptor structures pertaining to an ATSC A/90 Application shall provide an exhaustive list of all the MAC layer Multicast addresses present in the IP Multicast service.

9.3 Single IP Multicast Service in a Single Virtual Channel

9.3.1 Case of a Single IPM Program Element
In this scenario, an IP Multicast service consists of a unique IP Multicast session and both the SDP datagram stream and the IP Multicast media streams are conveyed in one data Program Element. The ATSC A/90 Application listing this IP Multicast service includes one Tap for referencing the MPEG-2 Program Element conveying the IP Multicast datagrams. The referencing mechanism is done according to the ATSC A/90 specification. Consequently, an association_tag_descriptor structure is inserted in the ES_info loop of the PMT associated with the ATSC Virtual Channel where the IP Multicast service is delivered.
It may happen that the IPM Program Element is not part of the MPEG-2 Program, or it is not part of the same MPEG-2 Transport Stream associated with the ATSC Virtual Channel where the IP Multicast service is provided. In both cases, the DSM-CC deferredMPEGProgramElement resource descriptor is included in the ATSC A/90 Network Resource Table to allow unambiguous identification of the location of the IPM Program Element in the external MPEG-2 Program or MPEG-2 Transport Stream.

9.3.2 Case of Multiple IPM Program Elements
In this scenario, multiple data Program Elements are used to convey the SDP stream and the IP Multicast media streams. Per ATSC A/90 [1)], at least one Tap is associated with each Program Element conveying the datagrams of the IP Multicast session.

9.3.3 Taps and Application
All Taps are listed in the Data Service Table as belonging to a single data application. When multiple Program Elements are used to carry the IP Multicast session, it is possible to assign distinct leak rates and maximum bit rates to each Program Element as described in the ATSC A/90 specification.

9.4 Multiple IP Multicast Sessions on a Single Virtual Channel
It is possible to have multiple IP Multicast sessions bound to the same Virtual Channel within the same ATSC Transport Stream. This is applicable whether the IP Multicast service is a stand-alone service or a service related to an audio-visual event. In this case, each individual media stream (the IP datagrams conveying the media datagrams of one SDP session) may be conveyed in a distinct set of MPEG-2 Program Elements.
It is possible that an author may create multiple session instances within a single IP Multicast session, for example to provide multiple language options. These multiple sessions would be announced in the standard SDP fields. As in the previous case, there is at least one Tap associated with each MPEG-2 Program Element conveying datagrams of the IP Multicast service.
The IP Multicast sessions may be conveyed in a single or in multiple A/90 Applications.

9.4.1 Single Application
It may be desirable to group all IP Multicast sessions in a single ATSC A/90 Application. Individual applications are not announced in the standardized program guide (PSIP) and therefore, session selection and schedule cannot be based solely on PSIP. A receiver that finds an application with data Program Elements conveying IP Multicast data will have to monitor these streams to collect the SDP packets. The receiver application is responsible for sorting the streams out at the IP network layer based on the information in the union of the SDP announcements. The information retrieved from SDP packets is then used to request session selection from users, for example, by using a small menu superimposed on the screen.

9.4.2 Multiple Applications
Instead of inserting all IP Multicast sessions into one ATSC A/90 application, it is also possible to use a separate application per session. The collection of applications is called in A/90 a Data Service. Individual applications in a single Data Service are not announced in the standardized program guide (PSIP) and therefore, session selection and schedule cannot be based solely on PSIP. In this case, a receiver that finds multiple applications with IP Multicast content will have to monitor all the Program Elements that carry IP Multicast. The receiver then collects the SDP packets that can be used to offer session selection to users.

9.5 Multiple IP Multicast Services on Multiple Virtual Channels
Instead of inserting all IP Multicast sessions in a single virtual channel, it is also possible to use a different virtual channel per session. In this case, each virtual channel may reference the same video and audio elementary streams in the PSIP Service Location Descriptor associated with the Virtual Channel (each Virtual Channel of course, has a corresponding MPEG-2 Program and PMT). This permits the use of EIT-k's or DET-k's to announce the schedule, rating and name of each session. The advantage of this option is that users searching for a particular session may do so by navigating the channel lists of the standardized program guide (PSIP).

10. BUFFER MODEL
There is an IP Multicast application buffer for each Program Element referenced by a Tap of protocol_encapsulation value 0x04. Only IP Multicast datagrams enter the IP Multicast application buffer. Other bytes are discarded and may be used to control the system. Bytes enter the IP Multicast application buffer at the rate specified by the sb_leak parameter associated with the profile of the data service or by the sb_leak_rate field in the smoothing_buffer_descriptor associated with the Program Element conveying the IP Multicast datagrams.

The size of the IP Multicast application buffer shall be equal to 262144 bytes. The IP Multicast datagrams shall be sent such that the IP Multicast application buffer shall not overflow.
This corresponds to the acquisition of 65536 bytes UDP datagrams on two distinct ports, with the assumption that one UDP datagram is being removed from the buffer while another one is being aggregated in the buffer. Bytes of a UDP datagram payload are removed out of the application buffer once it has been reconstructed in the application buffer.
The application buffer corresponds to the collection of buffers IPGRMBnk, FRAGBnkj, and UDPnkji defined in Section 17.

11. SCRAMBLING OF MAC LAYER MULTICAST ADDRESSES
The method for scrambling the deviceId fields and/or the payload of DSMCC_Addressable_section structures is outside the scope of this specification.

11.1 Payload Scrambling
The payload of DSMCC_addressable_section structures may be scrambled. In this case, scrambling is signaled by means of the 2-bit payload_scrambling_control field in the DSMCC_addressable_section header, as specified by the ATSC A/90 Data Broadcast standard.

11.2 Device Identifier Scrambling
The deviceId fields in a DSMCC_addressable_section structure may be scrambled or not scrambled. The presence of scrambling is signaled by the 2-bit field address_scrambling_control in the header bytes of the DSMCC_addressable_section structure. Scrambling has been applied when this field is greater than 0. A MAC layer Multicast address in the DSMCC_addressable_section structure should map to a MAC layer Multicast address appearing either in the Tap selector_type 0x0102 structure or in the MAC_Address_List_descriptor structure within the DST of the ATSC A/90 Application to which the IP Multicast service belongs.
Normative Clause
MAC layer Multicast addresses appearing as scrambled in the header bytes of the DSMCC_addressable_section shall also appear as scrambled if referenced in the Data Service Table.

12. ACQUISITION PROCEDURE
The acquisition of the IP Multicast service is based on the various ISO/IEC 13818-1, ATSC PSIP [2)] and ATSC A/90 [1)] structures.
The Virtual Channel Table (VCT) is transmitted in Transport Stream packets referenced by the PID value 0x1FFB. The source_id field associated with the virtual channel in the VCT allows for the identification of the instances of the Event Information Tables (EIT-k's) announcing the audio-visual event schedule. It also identifies the instances of the Data Event Tables (DET-k's) announcing the schedule of the associated IP Multicast service. The location of the EIT-k's and DET-k's in the Transport Stream is specified in the PSIP Master Guide Table. The instances of the DET-k's conveying the IP Multicast service schedule include a title text structure that may be reported in the on-screen display of the Program Guide.
The audio, video, and IPM Program Elements belong to the same virtual channel so the audio-visual event can be enhanced by the IP Multicast service.
The PSIP Service Location Descriptor in the VCT is used to aggregate the MPEG-2 Program Elements making up the virtual channel. A virtual channel with an IP Multicast service includes one and only one MPEG-2 Program Element of stream_type 0x95. The elementary_PID value PID1 associated with the Program Element of stream_type value 0x95 specifies the Transport Stream packets conveying the Data Service Table and the Network Resources Table in the virtual channel. The elementary_PID value PID2 of stream_type value 0x0D identifies the Transport Stream packets conveying the DSM-CC Addressable sections where the IP Multicast datagrams are encapsulated. The elementary_PID values PID1 and PID2 are also listed in the PMT. The virtual channel may include additional elementary_PID values for video and audio streams.
The Program Association Table (PAT) in the ATSC Transport Stream identifies the PID value of the Transport Stream packets conveying the Program Map Table (PMT). The PMT includes an MPEG-2 Program featuring the video, audio, and IP Multicast data Program Elements aggregated by the virtual channel. The MPEG-2 Program number in the PAT and the PMT match the program number associated with the virtual channel listed in the VCT.
In the example, the Data Service Table consists of one IP Multicast application featuring one Tap structure. The Tap structure includes an associationTag allowing identification of the location (the elementary_PID value) of the IPM Program Element within the ATSC Transport Stream. The elementary_PID value associated with the IPM Program Element is obtained by matching the associationTag value in the Tap structure with the associationTag value in the Association Tag Descriptor within the PMT. The Tap information loop includes a Multiprotocol Encapsulation Descriptor to signal the number of active bytes used in the deviceId fields of the DSM-CC Addressable Sections. The deviceId_address_range field value is set to 0x06 to indicate that all deviceId bytes are active. The deviceId_mapping_flag is set to 1 to indicate that deviceId fields represent a MAC multicast address.
The Session Description Protocol datagrams are received in DSM-CC Addressable Sections with deviceId fields representing the SDP IP Multicast address. The SDP datagrams publish the IP Multicast address(es) of the IP Multicast media streams that make up the IP Multicast session. These non-SDP data streams can be filtered appropriately by the receiver based on the value of the deviceId fields in the DSM-CC Addressable Section header bytes, or at the IP network layer.
In this example, all IP Multicast datagrams are carried in the same data Program Element, and thus are not announced in separate Taps in the DST.

13. NETWORK RESOURCE TABLE (NRT)
External media streams or SDP records belonging to the IP Multicast Service and located in other Virtual Channels, other ATSC transports, or in another IP network of the receiver are required by A/90 to be signaled in the Network Resource Table (NRT). In general, the NRT is used when either:
1) IP datagrams are conveyed in a data Program Element belonging to an MPEG-2 Program or an ATSC Transport Stream other than the one used to convey the Data Service Table of the IP Multicast service, or
2) The receiver application consuming this service requires access to external Internet network.

14. IMPLEMENTATION INFORMATION ON THE IP NETWORK MODEL
The following items are considerations and ramifications of the IP Network Model defined in Section 4.
When a Program Element (in Transport packet format) is passed through any piece of equipment that can insert or re-multiplex Program Elements (i.e., a multiplexor), one must make the conscious decision about whether that piece of equipment is acting as a bridge or a router. The latter would require enforcement of packet scoping rules, decrementing of Time-To-Live (TTL) values, etc. It is expected that most broadcast equipment will initially operate as bridges to avoid having to modify the streams.
When it is known that a Program Element carries IP data, multiplexing of new IP data into the same Program Element must be done with care. The precaution in this case is the need to ensure that there is no conflict between IP addresses of the old and new data.
Administratively scoped packets can only be inserted at the last route before emission. Since in the general case, this point is not known to the content author, it is difficult to use administratively scoped addresses unless the communication is known to be between the emission station and the receiver, such as for service and maintenance. This case ensures a single route. Network topologies such as local 1394 networks at the receiver end prevent any practical use of administratively scoped addresses by general content authors, often including broadcast studios.
Administratively scoped packets cannot be forwarded across a multiplexor that is acting as a router.
When crossing any router, then the TTL must be decremented by that router. Thus, a TTL value of 1 should not be used when authoring, even in the broadcaster studio.
And, from a receiver application perspective, each Program Element is necessarily its own network interface model.
The above are just some relevant examples. Consult general IP network guidelines from IETF for more information and details.
IP MULTICAST BUFFER MODEL
The application buffer model for acquisition of the IP Multicast datagrams assumes that datagrams are carried in UDP datagrams encapsulated in IP datagrams.

Complete Transport Stream packets containing data from Program Element n are passed to the transport buffer for data Program Element n, TBn. The size of TBn is fixed at 512 bytes. All bytes that enter TBn are removed from TBn at a rate Rxn = 1.2 Rmax[ profile ], where Rmax [ profile ] is the maximum data rate associated with the data service profile as specified by the data service profile. When there is no data in buffer TBn, rate RXn is equal to zero. Duplicate Transport Stream packets are not delivered to SBn. The Transport Stream buffer is not allowed to overflow.
Only the header of DSMCC_addressable_section structures, payload, and CRC_32 data bytes are delivered to buffer SBn; all other bytes do not enter SBn and may be used to control the system. The size of SBn is specified by data service profile. If there is data in buffer SBn, the data is taken out of SBn at a rate specified by sb_leak, the leak value specified by the data service or by the smoothing buffer descriptor associated with the IPM Program Element n. The buffer SBn is not allowed overflow.
The IP Multicast datagram bytes in buffer SBn are all delivered to their associated IP datagrams buffer at the rate specified by data service profile or by the smoothing buffer descriptor associated with the IPM Program Element n. Only IP datagram payload data bytes for IP Multicast address k enter buffer IPGRMBnk. Bytes from the DSM-CC Addressable section header bytes carrying bytes of a datagram of IP Multicast k in data Program Element n are discarded and may be used to control the system. Bytes from the DSM-CC Addressable section CRC_32 fields that immediately follow the last IP datagram byte are discarded and may be used to verify the integrity of the data. When there is no DSM-CC Addressable section data present in SBn, no data is removed from SBn. All data that enters SBn leaves it. All DSM-CC Addressable section payload bytes of data Program Element n enter the IP de-multiplexor instantaneously upon leaving SBn. DSM-CC Addressable section header bytes and CRC32 bytes are removed instantaneously upon leaving SBn. The buffer IPGRMBnk is not allowed to overflow.
The payload bytes of the IP Multicast datagrams in buffer IPGRMBnk are all delivered to their associated IP Fragmentation buffer at the rate specified by the data service profile or by the smoothing buffer descriptor associated with the IPM Program Element n. Only IP datagram data bytes of fragment pertaining to identification j of IP datagram with IP Multicast address k in data Program Element n enter buffer FRAGnkj. Bytes from the IP datagram header are discarded and may be used to control the system and verify the integrity of the IP header. When there is no IP datagrams data present in IPGRMBnk, no data is removed from IPGRMBnk. All data that enters IPGRMBnk leaves it. All IP datagram payload bytes of IP Multicast address k in data Program Element n enter the Fragmentation de-multiplexor instantaneously upon leaving IPGRMBnk. IP datagram header bytes are removed instantaneously upon leaving IPGRMBnk. The buffer FRAGbnkj is not allowed to overflow.
The IP datagram fragment data bytes in buffer FRAGBnkj are used to reconstruct the original, non-fragmented, IP datagram payload. Last fragment pertaining to a re-constructed datagram may be identified by means of the control fragmentation flag bit in the IP datagram header. The payload bytes of the original, non-fragmented, IP datagram are all delivered to the UDP buffer at a rate specified by the data service profile or by the smoothing buffer descriptor associated with the IPM Program Element n. Only UDP PDU payload data bytes of destination port i of the IP datagram re-constructed under fragmentation identifier j of the IP datagram with IP Multicast address k in data Program Element n enter buffer UDPnkji. Bytes from the UDP PDU header are discarded and may be used to control the system and may be used to verify the integrity of the IP pseudo-header. When there are no IP payload data bytes in the FRAGBnkj buffer, no data is removed from FRAGBnkj. All data that enters FLAGBnkj leaves it. All IP datagram payload bytes belonging to fragmentation of identification j of IP Multicast address k in data Program Element n enter the UDP de-multiplexor instantaneously upon leaving FRAGBnkj. UDP PDU header bytes are removed instantaneously upon leaving FRAGBnkj. The buffer UDPnkji is not allowed to overflow.
Once a UDP datagram has been fully reconstructed, the payload data bytes of the UDP PDU in buffer UDPnkji are all delivered at the rate specified by the data service profile or by the smoothing buffer descriptor associated with the IPM Program Element n. Only UDP PDU payload data bytes are delivered to the output at a rate specified by the data service or by the smoothing buffer descriptor associated with the IPM Program Element n. Other bytes are discarded and may be used to control the system. When there is no UDP PDU data present in UDPnkji, no data is removed from UDPnkji. All data that enter UDPnkji leaves it. UDP PDU header bytes are removed instantaneously upon leaving UDPnkji. The buffer UDPnkji is not allowed to overflow. The size of the IPGRMBnk, FRAGBnkj, and UDPBnkji is IPGRMBSnk, FRAGBSnkj, and UDPBSnkji, respectively.

15. MAC ADDRESS LIST DESCRIPTOR (NORMATIVE)
The MAC_Address_List_descriptor structure shall conform to the syntax and semantics defined below:

MAC_Address_List_descriptor() {
descriptor_tag 8bits (uimsbf)
descriptor_length 8bits (uimsbf)
mac_addr_list 1 bit (bslbf)
mac_addr_range 1bit (bslbf)
pdu_size 2bits (bslbf)
encapsulation_type 2bits (bslbf)
reserved 2bits '11'
if( mac_addr_list == '1'){
num_in_mac_lis 8bits (uimsbf)
for( i =0; i < num_in_mac_list; i++){
mac_address 48bits (uimsbf)
}
}
if( mac_addr_range == '1'){
num_of_mac_ranges 8bits (uimsbf)
for( i=0; i<num_of_mac_ranges; i++){
highest_mac_address 48bits (uimsbf)
lowest_mac_address 48bits (uimsbf)
}
}
for( i =0; i < K; i++)
private_data_byte 8bits (uimsbf)
}
}

This descriptor was originally defined by SCTE [11].
descriptor tag This 8-bit field shall have the value 0xAC to identify this descriptor as a MAC_Address_List_descriptor.
descriptor_length This 8-bit field shall specify the length in bytes of the fields immediately following this field up to the end of this descriptor.
mac_addr_list This 1-bit field shall be to '1' if the descriptor includes a set of destination MAC addresses. This field shall be set to '0' otherwise.
mac_addr_range This 1-bit field shall be set to '1' if the descriptor includes a range of destination MAC addresses where the range is specified by the highest_mac_address and lowest_mac_address fields. This field shall be set to '0' otherwise.
pdu_size This 2-bit field shall indicate the maximum length of IP datagram fragments encapsulated in the associated DSM-CC Program Element. Value 00 shall mean up to 1024 byte sections and 11 shall mean up to 4096 byte sections. Other values are reserved.
encapsulation_type This 2-bit field shall indicate the type of multiprotocol encapsulation performed on sections. Value '00' is DVB MPE (datagram_section structure). '11' is ATSC MPE (DSMCC_addressable_section structure). Other values are reserved.
num_of_mac_list This 8-bit field shall indicate the number of MAC addresses contained within this descriptor.
num_of_mac_ranges This 8-bit field shall indicate the number of MAC addresses pairs with a high/low range contained within this descriptor.
mac_address This 48-bit field shall specify a MAC group address.
highest_mac_address This 48-bit field shall specify the value of the largest group MAC address listed in this descriptor.
lowest_mac_address This 48-bit field shall specify the value of the smallest group MAC address listed in this descriptor.
private_data_byte This 8-bit field shall represent a byte of any additional information that may be used to identify the stream of datagrams.

Follow-Ups:
- Re: draft-ipmulticast-ipdvb-awa-01.txt
  - From: Marshall Eubanks <tme@multicasttech.com>

Prev by Date: draft-fair-ipdvb-ar-01.txt
Next by Date: Re: draft-ipmulticast-ipdvb-awa-01.txt
Previous by thread: draft-fair-ipdvb-ar-01.txt
Next by thread: Re: draft-ipmulticast-ipdvb-awa-01.txt
Index(es):
- Date
- Thread