SMPTE ST 2071-2-2016 Media Device Control Protocol (MDCP) (Includes Access to Additional Content).pdf

《SMPTE ST 2071-2-2016 Media Device Control Protocol (MDCP) (Includes Access to Additional Content).pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 2071-2-2016 Media Device Control Protocol (MDCP) (Includes Access to Additional Content).pdf（11页珍藏版）》请在麦多课文档分享上搜索。

1、Access to Content for (SMPTE ST 2071-2:2016 ) (Click here to view the publication) This Page is not part of the original publication: This page has been created by IHS as a convenience to the user in order to provide access to the content as authorized by the Copyright holder of this document. Click

2、 the link(s) below to access the content and use normal procedures for downloading or opening the files. SMPTE_Additional Data Information contained in the above is the property of the Copyright holder and all Notice of Disclaimer or that a certain course of action is preferred but not necessarily r

3、equired; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document. The keyword “reserved” indicates a provision that is not defined at this tim

4、e, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future. A conformant implementation according to this document is one that includes all mandatory provisions (“shall“) and, i

5、f implemented, all recommended provisions (“should“) as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. Unless otherwise specified, the order of precedence of the types of normative information in this document shall be

6、as follows: Normative prose shall be the authoritative definition; Tables shall be next; followed by formal languages; then figures; and then any other language forms. SMPTE ST 2071-2:2016 Page 4 of 10 Pages 3 Document Elements The SMPTE 2071 suite is comprised of the following elements, which form

7、an integral piece of this Standard. Additionally, the WSDL and schema files may be found at http:/smpte-ra.org/schemas/2071/2015. 1. Prose ST2071-2.docx Normative 2. XML Schema st2071-2a.xsd http:/www.smpte-ra.org/schemas/st2071/2015/types Normative 3. XML Schema st2071-2b.xsd http:/www.smpte-ra.org

8、/schemas/st2071/2015/identity Normative 4. XML Schema st2071-2c.xsd http:/www.smpte-ra.org/schemas/st2071/2015/device Normative 5. XML Schema st2071-2d.xsd http:/www.smpte-ra.org/schemas/st2071/2015/session Normative 6. XML Schema st2071-2e.xsd http:/www.smpte-ra.org/schemas/st2071/2015/event Normat

9、ive 7. XML Schema st2071-2f.xsd http:/www.smpte-ra.org/schemas/st2071/2015/mode Normative 8. XML Schema st2071-2g.xsd http:/www.smpte-ra.org/schemas/st2071/2015/media Normative 9. XML Schema st2071-2h.xsd http:/www.smpte-ra.org/schemas/st2071/2015/query Normative 10. XML Schema st2071-2i.xsd http:/w

10、ww.smpte-ra.org/schemas/st2071/2015/security Normative 11. WSDL st2071-2j.wsdl http:/www.smpte-ra.org/schemas/st2071/2015/device Normative 12. WSDL st2071-2k.wsdl http:/www.smpte-ra.org/schemas/st2071/2015/session Normative 13. WSDL st2071-2l.wsdl http:/www.smpte-ra.org/schemas/st2071/2015/event Nor

11、mative 14. WSDL st2071-2m.wsdl http:/www.smpte-ra.org/schemas/st2071/2015/mode Normative 15. WSDL st2071-2n.wsdl http:/www.smpte-ra.org/schemas/st2071/2015/media Normative 16. WSDL st2071-2o.wsdl http:/www.smpte-ra.org/schemas/st2071/2015/query Normative 17. WSDL st2071-2p.wsdl http:/www.smpte-ra.or

12、g/schemas/st2071/2015/security Normative 18. XML Schema st2071-2q.xsd http:/www.smpte-ra.org/schemas/st2071/2015/service Normative 19. WSDL st2071-2r.wsdl http:/www.smpte-ra.org/schemas/st2071/2015/service Normative 4 Normative References The following standards contain provisions that, through refe

13、rence in this text, constitute provisions of this recommended practice. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this recommended practice are encouraged to investigate the possibility of applying the mos

14、t recent edition of the standards indicated below. SMPTE ST 2071-1:2016, Media Device Control Framework (MDCF) IETF RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers SMPTE ST 2071-2:2016 Page 5 of 10 Pages IETF RFC 3168, The Addition of Explicit Conges

15、tion Notification (ECN) to IP IETF RFC 3246, An Expedited Forwarding PHB IETF RFC 4122, A Universally Unique Identifier (UUID) URN Namespace OASIS WS-I BP 1.2, Organization for the Advancement of Structured Information Standards (OASIS) Web Services Interoperability (WS-I) Basic Profile Version 1.2

16、5 Messaging Services Messages are data packets exchanged between nodes for the purpose of executing operations, broadcasting notification events, and exchanging data. The Media Device Control specification defines this exchange of messages as the Media Device Control Protocol (MDCP). The Media Devic

17、e Control Protocol (MDCP) shall be implemented in accordance to the OASIS Basic Profile 1.2 (OASIS WS-I BP 1.2) web services specification, using the SOAP 1.1 HTTP protocol binding. Service definitions shall be represented using Web Service Definition Language version 1.1 (WSDL 1.1) and may use WS-A

18、ddressing 1.0 for the addressing of request and/or response messages. 6 The MDCF Data and Operation Model In compliance with the OASIS WS-I Basic Profile 1.2 the MDCF data and operation model shall be transposed to XML Schema 1.0 and WSDL 1.1. The WSDL and the corresponding SOAP envelopes shall conf

19、orm to the requirements outlined in the OASIS WS-I Basic Profile 1.2 and the SOAP 1.1 in HTTP protocol binding. 6.1 Mapping the MDCF Data Model to WSDL When transposing the MDCF data and operations model to XML 1.0 and WSDL 1.1 the following rules shall apply: 1. MDCF attributes shall be mapped to d

20、ocument-literal port type operations with an operation name equal to the word “get” prepended to the attribute name as it is defined in the MDCF data and operations model. For example, an attribute named “SomeAttribute” would transpose to a port type operation named “getSomeAttribute”. The resulting

21、 operation shall accept no input parts and shall specify one output part matching the data type of the attribute. 2. MDCF operations shall be mapped to document-literal port type operations with an operation name equal to the name as it is assigned to the operation in the MDCF data and operations mo

22、del. For example, an operation named “SomeOperation” would transpose to a port type operation named “SomeOperation”. The resulting operation shall accept only one input part, containing an XML document representing the input parameters of the operation and one output part matching the return type of

23、 the operation. 3. Port type operations shall define faults representative of the error conditions that may arise. Errors conditions that invalidate the state of the operation shall terminate the operation and raise the appropriate fault. 4. Each port type operation shall specify a unique WS-Address

24、ing 1.0 compliant Action attribute for both the input and output message parts. SMPTE ST 2071-2:2016 Page 6 of 10 Pages 6.2 Message Format and Structure 6.2.1 SOAP Envelope The standard SOAP 1.1 envelope shall be used. The SOAP 1.1 Binding for MTOM 1.0 may be used to transport binary data or improve

25、 the performance of large result sets. 6.2.2 SOAP Headers The web services endpoint may require the support of WS-Addressing 1.0. 6.2.2.1 MessageID The MessageID header shall be specified if WS-Addressing 1.0 support is indicated. The MessageID shall be a UUID as defined by RFC 4122. For example: ur

26、n:uuid:12345678-1234-1234-1234-123456789abc 6.2.2.2 To The To header may be specified if WS-Addressing 1.0 support is indicated. The To header shall contain the endpoint address of the SOAP receiver. 6.2.2.3 ReplyTo The ReplyTo header may be specified if WS-Addressing 1.0 support is indicated. The R

27、eplyTo header shall contain the endpoint address of the SOAP sender. 6.2.2.4 Action The Action header shall be specified if WS-Addressing 1.0 support is indicated. The Action header shall be derived from the Action attribute specified in the WSDL for the operation message part. If no Action attribut

28、e is specified for the operation message part, the value of the Action header shall be derived implicitly from the WSDL, refer to the WS-Addressing 1.0 documentation for specific details. 6.2.2.5 RelatesTo The RelatesTo header may be specified if WS-Addressing 1.0 support is indicated. The RelatesTo

29、 header shall contain the MessageID of the corresponding request. 6.2.3 SOAP Body The SOAP Body shall be specified in accordance to the OASIS WS-I Basic Profile 1.2, containing only one child XML element. 7 Device and Service Web Services Devices and Services are aggregations of Capabilities, implem

30、enting more than one Capability Interface. In order to represent this relationship in WSDL, each Device or Service may be described as a WSDL service. If implemented, the WSDL service shall describe each exposed Capability Interface as a distinct web service endpoint and the URLs attribute of the De

31、vice or Service Capability shall contain one or more URLs that facilitate the connection to that interface. SMPTE ST 2071-2:2016 Page 7 of 10 Pages 7.1 Device and Service Endpoints Each Capability Interface shall be exposed as a unique web service endpoint. Each web service endpoint shall be defined

32、 as a unique WSDL port type and there shall be a one to one relationship between the Capability Interfaces exposed by a Device or Service and the web service endpoints exposed by that Device or Service. The URLs attribute of the Capability data structure shall contain one or more URLs that facilitat

33、e the connection to the web service endpoint represented by that Capability data structure. 8 Map Data Type Representation The Map data type defined within the MDCF requires a protocol specific binding for the conveyance of the data stored within the values of the Map entries. Therefore, MDCP implem

34、entations shall encode the Map entry values using the predefined XML base types. The values shall be stored within the Map entry XML elements encoded as prescribed within Table 1. Table 1 Map Entry Value Encoding Name Encoding BOOLEAN Shall be represented as an XML string type. TRUE = “TRUE”, FALSE

35、= “FALSE”. STRING Shall be represented as an XML string type. INTEGER Shall be represented as an XML string type. FLOAT Shall be represented as an XML string type. DATE_TIME Shall be represented as an XML dateTime type. URI Shall be represented as an XML anyURI type. MAP Shall be represented as an X

36、ML string type, with escaping of reserved characters. BLOB Shall be represented as an XML base64Binary type. 9 Internet Protocol Considerations 9.1 The Differentiated Services Field (DS Field) The Differentiated Services Field (DS Field) RFC 2474 is an IP header field used to classify IP packets for

37、 Quality of Service (QoS) strategies. In order to specify that the MDCP IP packets require low delay, low jitter, and low loss, MDCP implementations should set the value of the DS Field within the IPv4 and IPv6 header to the binary value 101110xx, where x may be either 0 or 1 (hexadecimal values 0xB

38、8, 0xB9, 0xBA, or 0xBB). 9.2 Explicit Congestion Notification (ECN) RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP, defines a method by which bits 6 and 7 of the DS Field are used to indicate network congestion without the dropping of IP packets. MDCP implementations should i

39、mplement ECN as defined by RFC 3168, but may also implement additional methods of Congestion Notification. SMPTE ST 2071-2:2016 Page 8 of 10 Pages Annex A Network Considerations (Informative) To facilitate the real-time control of devices and services within the network, Media Device Control Protoco

40、l (MDCP) Internet Protocol (IP) packets are expected to have a deterministic low latent period. Meaning that the packets are expected to traverse the network in a minimal amount of time, with little deviation in the inter-packet latencies. However, the same networks that are used for the MDCP are al

41、so used for the transmission of large media essence streams that pose a risk to the deterministic low latency requirement of the MDCP. To mitigate this risk, special considerations must be made to provide the network infrastructure with instructions on how to properly handle the MDCP IP packets. A.1

42、 The Differentiated Services Field (DS Field) The Differentiated Services Field (DS Field) RFC 2474 is a replacement header field for the IPv4 TOS octet RFC 791 and the IPv6 Traffic Class octet RFC 2460. The low-order 6 bits (DS0 DS5) of the DS Field are used for the Differentiated Services Codepoin

43、t (DSCP) and the 2 high-order bits (DS6 & DS7) for the Currently Unused (CU) field. The DSCP is used to specify the Per-Hop Behavior (PHB) that the marked packet will experience at each node within the network (also known as a “hop”) and is capable of representing 64 distinct codepoints, 32 of which

44、 are assigned through Standards Action and the remaining 32 are reserved for Local Use. Several standard PHBs have been defined to specify the standard set of routing and forwarding behaviors that can be applied to packets within a network. A.1.1 RFC 3246 An Expedited Forwarding PHB (EF PHB) RFC 324

45、6 An Expedited Forwarding PHB (EF PHB) specifies the PHB for low delay, low jitter, and low loss network services. The EF PHB is the highest priority PHB that can be assigned to an application level protocol (protocols that are not used to facilitate networking and routing) and is designated with th

46、e 6 bit binary value 101110. The EF PHB is regularly used for the audio essence in Voice over IP (VoIP) applications. The MDCP specifies the use of the EF PHB to facilitate its deterministic low-latency requirement. Therefore, the DS Field of a MDCP IP packet header is expected to contain a hexadeci

47、mal value of 0xB8, 0xB9, 0xBA, or 0xBB (binary 101110xx, where x may be either 0 or 1). A.2 Explicit Congestion Notification (ECN) Explicit Congestion Notification (ECN) RFC 3168 provides a mechanism by which network nodes can indicate persistent network congestion, without dropping packets. The ECN

48、 specification uses the CU field of the DS Field (the high-order 2 bits of the DS Field) to indicate whether a network node supports ECN and whether the network is experiencing persistent congestion. The following table indicates the meaning of each ECN bit pattern. Table A.1 ECN Bit Patterns ECN Bi

49、ts Meaning 0 0 The network node does not support ECN. 0 1 ECN is Supported. 1 0 ECN is Supported. 1 1 ECN is Supported and congestion is present. A packet would have been dropped. SMPTE ST 2071-2:2016 Page 9 of 10 Pages A.2.1 Network Zoning In most practical applications, special purpose networks, such as device control networks, must coexist and integrate with other functional networks. Each of these functional networks can be viewed as a zone, with each zone having a distinct set of requirements and traffic