SMPTE ST 2021-2-2015 Broadcast Exchange Format (BXF) - Protocol.pdf

1、 _ SMPTE ST 2021-2:2015 Revision of SMPTE ST 2021-2:2012 SMPTE STANDARD Broadcast Exchange Format (BXF) Protocol _ Copyright 2015 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10607 (914) 761-1100 Approved October 9, 2015 SMPTE ST 2021-2:2015 SMPTE 2015

2、All rights reserved Page 2 Table of Contents Page Foreword 3 Intellectual Property . 3 Introduction 3 1 Scope 4 2 Conformance Notation 4 3 Document Elements . 5 4 Normative References 5 5 Protocol . 5 5.1 Connectionless Transport 5 5.2 Connection-Oriented Transport . 5 5.2.1 TCP/IP . 5 5.2.2 Encrypt

3、ion 8 5.2.3 Message Format 8 5.3 File-Based Transport 9 5.3.1 File Name 9 SMPTE ST 2021-2:2015 SMPTE 2015 All rights reserved Page 3 Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally recognized standards developing organization. Headquartered and incorpora

4、ted in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineering Documents, including Standards, Recommended Practices and Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participation in these Committees is open to all with a bo

5、na fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual. SMPTE ST 2021-2 was prepared by Technology Committee 34CS

6、 Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Standard. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall

7、not be held responsible for identifying any or all such patent rights. Introduction This section is entirely informative and does not form an integral part of this Engineering Document. Broadcast Exchange Format (BXF) is a protocol for exchange of data among broadcast systems such as Traffic, Progra

8、m Management, Automation, and Content Distribution. It is intended to facilitate the movement of content and its associated metadata for better management, coordination and reporting between these broadcast systems. The BXF Protocol serves as a replacement for the many proprietary interfaces in plac

9、e today between vendors in these areas. Unless otherwise specified the order of precedence of the types of normative information in this document shall be as follows. Normative prose shall be the authoritative definition. Tables shall be next, followed by formal languages, then figures, and then any

10、 other language forms. In the event of a conflict between the schema and other information in this document, the schema is authoritative. SMPTE ST 2021 (BXF) is broken into several parts. A brief outline of the parts can be found in SMPTE OV 2021-0, the Document Overview to this suite of documents.

11、SMPTE ST 2021-2:2015 SMPTE 2015 All rights reserved Page 4 1 Scope Generally, the Broadcast eXchange Format (BXF) defines the format and content of XML Messages for the interchange of data and metadata among professional systems, as follows: 1. Broadcast schedules, including playout and record sched

12、ules 2. As run information 3. Content metadata, such as Content ID, Title, Duration, etc. 4. Content management requests such as dub and purge requests 5. Requests for transfer of content some of which will result in the transfer of Content essence between professional systems. 6. Ports as used by T

13、CP/IP for the exchange of messages The primary systems envisioned as users of this standard are: Program Management Systems Broadcast Traffic Systems Master Control Automation Systems Content Distribution Systems This particular document is focused on Protocol-related topics as they relate to BXF. T

14、he main BXF document (SMPTE ST 2021-1) should be read first, and this part (SMPTE ST 2021-2) should be considered as a companion to SMPTE ST 2021-1 for those interested in all things Protocol. 2 Conformance Notation Documents consist of normative text and, optionally, informative text. Normative tex

15、t is that describes elements of the design that are indispensable or contains the conformance language keywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting i

16、nteroperability. Informative text does not contain any conformance keywords. All text in a Standard, Recommended Practice, Amendment, Addendum, or Corrigendum, is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start wit

17、h “Note:” Normative references are external documents referenced in normative text that are indispensable to the user. Bibliographic references are references made in informative text or are those otherwise not indispensable to the user. Normative references shall conform to the types and procedures

18、 specified in the Engineering Administrative Practices. The keywords “shall“ and “shall not“ indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted. The keywords, “should“ and “should not“ indicate that, among several possibilities,

19、 one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. The keywords “may“ and “need

20、not“ indicate courses of action permissible within the limits of the document. The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision

21、 will never be defined in the future. A conformant implementation according to an Engineering Document is one that includes all mandatory provisions (“shall“) and, if implemented, all recommended provisions (“should“) as described. A conformant implementation need not implement optional provisions (

22、may“) and need not implement them as described. SMPTE ST 2021-2:2015 SMPTE 2015 All rights reserved Page 5 3 Document Elements The SMPTE ST 2021 suite is comprised of the following elements, which form an integral piece of this Standard. Additionally, the schema files may be found at http:/smpte-ra

23、org/schemas/2021/2015/BXF. (Accessible only by software applications for schema validation. Not intended to be human-accessible.) a) Prose document st2021-2-2015.pdf (this file) Normative b) XML schema st2021-2015.xml Normative c) HTML schema guide st2021-2015.html Informative 4 Normative Reference

24、s The following standards contain provisions, which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to invest

25、igate the possibility of applying the most recent edition of the standards indicated below. SMPTE ST 2021-1:2015, Broadcast Exchange Format (BXF) Requirements and Informative Notes SMPTE 2021 BXF Schema, http:/smpte-ra.org/schemas/2021/2015/BXF 5 Protocol The BXF protocol may be implemented using a

26、variety of transport mechanisms. The protocol supports both connection-oriented and connectionless approaches, two of which are described below: A connection-based transport for asynchronous communication and a connectionless file transport, for off-line and/or large sets of data that need to be com

27、municated. It is important to note that vendors may choose the appropriate transport mechanism for their applications. As a minimum, a BXF compliant system shall support a connectionless file transport. 5.1 Connectionless Transport Connectionless transport of BXF involves the exchange of files betwe

28、en systems. This is most commonly used by systems unable to support connection-oriented transport, or those needing to exchange very large datasets (e.g. exchange of a large collection of content metadata). This method involves one system placing the BXF file to be exchanged in a location from which

29、 that file is then retrieved by the receiving system(s). 5.2 Connection-Oriented Transport Connection-oriented transport of BXF requires a connection between the sending and receiving devices. BXF supports asynchronous messaging approaches, as described below. 5.2.1 TCP/IP TCP/IP protocol may be use

30、d for communication. The BXF application shall use a port number that is configurable by installation. BXF standard shall use 14544 and 14545 as default ports. 5.2.1.1 Connections Each device using the BXF protocol that receives and responds to messages shall act as a server (or service provider). E

31、ach device using the protocol to initiate the sending of messages shall act as a client (or service consumer). Devices that plan to both send and receive messages shall act as both a server and a client. SMPTE ST 2021-2:2015 SMPTE 2015 All rights reserved Page 6 A client shall initiate the connectio

32、n to a server. A device that includes both a server and a client shall be responsible for managing its client connection separately from the clients that connect to it. A client shall be allowed to open connections to as many BXF servers as are available. 5.2.1.2 Sending of Messages Once a connectio

33、n is made from a client to a server, only the client may initiate communication. This communication can either be a “push” of information where the client sends data to the server, or a “pull” where the client requests certain information from the server. If there is a need for the server to initiat

34、e messages to the client, then a separate connection shall be opened where the client/server roles are reversed. The initiating message will be consumed by the devices server, and its client will use a separate connection to acknowledge and reply (if applicable) to the original message. 5.2.1.3 Inac

35、tive Connections It is required that inactive and abnormal connections shall be detected and managed by transport protocols. In addition, clients may monitor the status of its connections to servers by sending heartbeat requests as defined later in this standard. Similarly, servers may monitor the s

36、tatus of connected clients and the transport connection by looking for heartbeat requests. The standard leaves managing failing connections and what to do in each case up to implementation. 5.2.1.4 List of Devices to Connect To or Accept Connections From Each device that is configured as a client/se

37、rver shall store a list of available devices (configured as servers) that it needs to communicate with. This list shall uniquely identify the device and its services. Arrangements for setting up and maintaining this list are left up to implementation by each manufacturer. 5.2.1.5 Initiation of Serve

38、rs When a device that is configured as a server is turned on, it shall begin accepting connections. When a client attempts to connect to the server, the server should reference its list of Devices to Accept Connections From (if present) before deciding to accept the connection. The system implementi

39、ng the protocol must not begin communications until it is able to fully support the messaging which it implements. 5.2.1.6 Timeout of Services BXF manages a state machine for processing of messages. In order to assure reliable communications, a timeout is specified. The default timeout of the BXF pr

40、otocol shall be 20 seconds. This timeout shall be defined as the maximum period of elapsed time from the completion of the message transmission, and the acknowledgment response from the receiving system, as measured at the client portion of the session. When this timeout is exceeded, the BXF protoco

41、l shall enter a retry loop or generate an error message, as determined by the implementer. SMPTE ST 2021-2:2015 SMPTE 2015 All rights reserved Page 7 L I S T E NP o r t : 1 4 5 4 4V A L I D A T ER e a d M e s s a g eA C KV a l i dN A KI n v a l i dP R O C E S SS t a r tR E P L YP o r t : 1 4 5 4 5R

42、e c e i v e L o o pR e p l y L o o p P r o c e s s i n gI n c o m i n gB X F M e s s a g eFigure 1 BXF State Machine, Receive SMPTE ST 2021-2:2015 SMPTE 2015 All rights reserved Page 8 M e s s a g e S e n d L o o pS E N DI D L EA c t i v a t eM e s s a g eS e n dO u t g o i n gB X F M e s s a g eL I

43、 S T E NP o r t 1 4 5 4 4W a i t2 0 S e c .C O U N TR e t r yR e s e n d / H e a r t b e a tA C K R e c e i v e dA L E R T T i m e o u tFigure 2 BXF State Machine, Transmit 5.2.2 Encryption System implementers may use methods of encryption, not specified herein, for secure communication within a sys

44、tem. The BXF protocol neither prohibits nor requires any specific security mechanism. It has been designed to be agnostic, and is therefore up to the end user to determine what, if any, security to use 5.2.3 Message Format All messages in BXF shall be sent as XML documents conforming to the BXF sche

45、ma as defined at http:/smpte-ra.org/schemas/2021/2015/BXF. 5.2.3.1 ACK Message Response An ACK message shall be sent indicating successful receipt of the message. Success is defined as the message having the following characteristics: The message is well-formed (it is an XML message and BXF complian

46、t) in the context of the receiving system and from a valid and recognized source The receiving system has implemented support for the message The message was received within the configuration timeout period 5.2.3.2 ACK Message Response with Errors or Invalid (NAK) Any message that fails the above te

47、sts shall return a new message with the appropriate error value as defined in the schema. SMPTE ST 2021-2:2015 SMPTE 2015 All rights reserved Page 9 5.3 File-Based Transport File-Based transfer may be used where large amounts of data need to be communicated from one system to another without the nee

48、d for acknowledgement, and where timing is not critical. The user simply downloads a file containing the XML document from the originating device and imports it into the receiving device. Alternatively, the files may be pushed or pulled to the receiving device in an automatic process. 5.3.1 File Nam

49、e The originating system shall utilize a common naming scheme for the files so that the receiving device can be set up to identify the files. The file name shall be in the format of: “BXFDateDevice1Device2GUID.xml” Where: Date shall be the year, month, and day that the file was sent (using UTC clock), in the format “yyyymm