SMPTE ST 2071-3-2014 Media Device Control Discovery (MDCD).pdf

《SMPTE ST 2071-3-2014 Media Device Control Discovery (MDCD).pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 2071-3-2014 Media Device Control Discovery (MDCD).pdf（37页珍藏版）》请在麦多课文档分享上搜索。

1、 Copyright 2014 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved May 13, 2014 Table of Contents Page Foreword . 2 Intellectual Property 2 Introduction 2 1 Scope . 3 2 Conformance Notation . 3 3 Normative References . 4 4 Name R

2、esolution (Informative) 4 4.1 Domain Name System (DNS) (Normative) 5 4.2 Multicast DNS (mDNS) (Normative) 5 5 DNS-Based Service Discovery (DNS-SD) . 6 6 Devices and DNS-Based Service Discovery (DNS-SD) 6 6.1 Capability Interfaces and Service Subtypes 6 7 DNS Resource Records for MDC Discovery . 7 7.

3、1 Pointer (PTR) Resource Record 7 7.2 Service (SRV) Resource Record . 8 7.3 Text (TXT) Resource Record . 9 7.4 Next-Secure (NSEC) Resource Record . 10 7.5 Constructing URLs from the SRV and TXT Resource Records 11 8 Zero Configuration . 11 8.1 Internet Protocol Version 4 (IPv4) Address Allocation .

4、11 8.2 Internet Protocol Version 6 (IPv6) Address Allocation . 11 8.3 Domain Name Servers . 11 8.4 Determining Browse Domains . 12 8.5 Finding Devices (Browsing) . 15 8.6 Making Devices Discoverable 16 Annex A Bibliography (Informative) . 19 Annex B DNS Primer (Informative) 20 B.1 What is the Domain

5、 Name System (DNS)? . 20 B.2 DNS Resource Records . 21 Annex C NS-SD Primer (Informative) . 31 C.1 What is the DNS-based Service Discovery (DNS-SD)? 31 C.2 DNS SD Design, Implementation and Examples . 32 C.3 DNS-Based Service Discovery (DNS-SD) DNS Resource Record Types 33 Page 1 of 37 pages SMPTE S

6、T 2071-3:2014 SMPTE STANDARD Media Device Control Discovery (MDCD) SMPTE ST 2071-3:2014 Page 2 of 37 Pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States o

7、f 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 bona fide interest in their

8、 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 of its Standards Operation Manual. SMPTE ST 2071-3 was prepared by Technology Committee 34CS. Intellectual Property

9、 At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held

10、 responsible for identifying any or all such patent rights. Introduction Since the inception of media devices there has been a continual need for a standardized means of controlling them. This need led to the initial creation of protocols such as de-facto, manufacturer based, serial RS-422 control o

11、n a 9-pin “D” connector, and later Video Disk Control Protocol (VDCP). However, unfortunately as technologies advanced and media devices became connected to Internet Protocol networks these methods were replaced with proprietary solutions. This Media Device Control suite of standards is intended to

12、address this issue and deliver the same level of interoperability as its predecessors, using Internet Protocol, with provisions for extensibility and adaptability. This document describes the provisions necessary for network-based discovery and Zero Configuration (ZeroConf), allowing MDC compliant d

13、evices to register themselves to the system and to locate other MDC devices, with little to no configuration. The provisions in this document are designed to scale from small, unmanaged networks to large enterprise networks and to the Internet, providing mechanisms to simplify configuration wherever

14、 possible. The following diagrams depict two MDC network configurations where MDC devices configure themselves to discover other MDC devices with little to no configuration, beyond that which is needed to access the network. The first diagram (Figure 1) depicts a network where MDC devices discover o

15、ne another utilizing DHCP and DNS. The second diagram (Figure 2) illustrates how a MDC compliant device and a MDC client can be connected, with a single network cable, and automatically configure themselves into a functioning Link-Local network, where the client can discover the device and interroga

16、te the device for its capabilities. Client Device DHCP Device Internet Devices Clients Non-MDC Devices Net mDNS DNS Figure 1 Device configuration via Figure 2 Two directly connected DHCP and DNS Devices using Link-Local SMPTE ST 2071-3:2014 Page 3 of 37 Pages 1 Scope This document describes the Zero

17、 Configuration (ZeroConf) and service discovery mechanisms defined for the Media Device Control (MDC) SMPTE ST 2071 suite of standards. Defining how MDC compliant devices utilize existing network services, or in the absence of such services, use existing Zero Configuration (ZeroConf) techniques and

18、standards to automatically construct a fully functional system. Design Goals Allow for the querying of devices and services within logical discovery domains. Allow for the separation of the discovery and primary name resolution infrastructures. Allow clients and devices to work around hardware and n

19、etwork failures, through discovery. Reduce and centralize the configuration required to create a functional Media Device Control system. Use common, well understood, and widely adopted standards and technologies. 2 Conformance Notation Normative text is text that describes elements of the design tha

20、t 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 interoperability. Informative text does not con

21、tain any conformance keywords. All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” The keywords “shall“ and “shall not“ indicate requirements strictly to be followed in order t

22、o conform to the document and from which no deviation is permitted. The keywords, “should“ and “should not“ indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessa

23、rily required; 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 th

24、is time, 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“)

25、and, if 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 sha

26、ll be 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-3:2014 Page 4 of 37 Pages 3 Normative References The following standards contain provisions that, through refere

27、nce 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 most

28、recent edition of the standards indicated below. IETF RFC 1034, Domain Names Concepts and Facilities IETF RFC 1035, Domain Names Implementation and Specification IETF RFC 1464, Using the Domain Name System to Store Arbitrary String Attributes IETF RFC 2131, Dynamic Host Configuration Protocol (DHCP)

29、 IETF RFC 2136, Dynamic Updates in the Domain Name System (DNS UPDATE) IETF RFC 2181, Clarifications to the DNS Specification IETF RFC 2782, A DNS RR for specifying the location of services (DNS SRV) IETF RFC 3007, Secure Domain Name System (DNS) Dynamic Updates IETF RFC 3315, Dynamic Host Configura

30、tion Protocol for IPv6 (DHCPv6) IETF RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses (IPv4LL) IETF RFC 4034, Resource Records for the DNS Security Extensions IETF RFC 4862, IPv6 Stateless Address Autoconfiguration IETF RFC 6106, IPv6 Router Advertisement Options for DNS Configuration IE

31、TF RFC 6762, Multicast DNS (mDNS). IETF RFC 6763, DNS-Based Service Discovery (DNS-SD) SMPTE ST 2071-1:2014, Media Device Control Framework (MDCF) SMPTE ST 2071-2:2014, Media Device Control Protocol (MDCP) 4 Name Resolution (Informative) Name resolution is the process of resolving human readable nam

32、es into protocol specific addresses. Name resolution can be provided in a centralized fashion, as a service, such as Domain Name System (DNS), or it can be provided as a decentralized broadcast based network protocol, such as Multicast DNS (mDNS) or Link-Local Multicast Name Resolution (LLMNR). If n

33、ame resolution is implemented as a service, the resolver sends a unicast request to the name resolution service and awaits a unicast response. If name resolution is implemented as a broadcast based network protocol, a querier broadcasts the name resolution request to a broadcast or multicast address

34、 and awaits responses from any services that may reply. In either methodology, one or more systems are configured to accept name resolution requests and to respond to those requests with the appropriate protocol specific addresses. Name resolution may also be used in reverse, to find the human reada

35、ble name for a protocol address in a process known as reverse mapping. SMPTE ST 2071-3:2014 Page 5 of 37 Pages The Domain Name System (DNS) (RFC 1034, RFC 1035, RFC 4795, and RFC 6762) is the standard name resolution service defined for Internet Protocol networks. At the time of this writing, the IE

36、TF defines three variants of DNS, one using a unicast service model, called Domain Name System (DNS) (RFC 1034 and RFC 1035) and two broadcast network protocol variants, using multicast UDP datagrams, known as Link-Local Multicast Name Resolution (LLMNR) RFC 4795 and Multicast DNS (mDNS) RFC 6762. W

37、hen using DNS, a client, known as a resolver, issues a unicast UDP or TCP name resolution request to the DNS name server. The DNS name server replies to the requestor in a unicast fashion, using either UDP or TCP, depending upon the protocol that was used for the request. When using LLMNR, the reque

38、stor broadcasts a request using a multicast UDP datagram and like DNS, the LLMNR service replies to the requestor in a unicast fashion. Multicast DNS (mDNS) is similar to LLMNR. However, the mDNS service, known as a querier, replies to the requestor in a multicast fashion, using multicast UDP datagr

39、ams. The multicast nature of the response allows all mDNS resolvers on the Link-Local network to receive and cache the name resolution responses for each request. This pre-caching allows mDNS resolvers to resolve future name resolution requests without generating network traffic. Both LLMNR and mDNS

40、 use the same data format as DNS for request and response data packets and the packets can be confused between the DNS variants. Therefore, each DNS variant is assigned a distinct default IP port number to prevent systemic issues caused by the minor differences between the DNS, LLMNR, and mDNS datag

41、rams. 4.1 Domain Name System (DNS) (Normative) The Domain Name System (DNS) (RFC 1034 and RFC 1035), the centralized, service-based name resolution service, shall be used to implement MDC Discovery. Domain Name System is the standard name resolution service defined for Internet Protocol networks. Th

42、e use of DNS allows MDCD to be implemented using existing, well defined, and well-understood technologies that are usually already present on the network. Please refer to Annex B DNS Primer (Informative) for further details regarding the Domain Name System (DNS). 4.2 Multicast DNS (mDNS) (Normative)

43、 Multicast DNS (mDNS) RFC 6762, the decentralized, broadcast based network protocol for name resolution, shall be used to implement MDC Discovery (MDCD). Multicast DNS (mDNS) is an extension of DNS that uses multicast UDP to broadcast name resolution requests and responses over the Link-Local networ

44、k. mDNS packets are nearly identical to DNS packets; however, extensions have been added to allow for a single mDNS packet to carry multiple name resolution requests and responses. Unlike LLMNR and DNS, mDNS queriers broadcast all name resolution responses and may receive unsolicited name resolution

45、 responses. mDNS queriers will cache name resolution responses, whether requested or not, for future use and to reduce the network traffic generated by service discovery. In later sections of this document, normative algorithms and processes are defined that use DNS and mDNS for MDC Discovery. Withi

46、n these algorithms the “local” and reverse mapping Link-Local domains will utilize mDNS for name resolution. All domains that are not designated as mDNS domains shall use unicast DNS for name resolution. The complete list of mDNS domains is listed in Table 1. Table 1 Multicast DNS (mDNS) Domains Int

47、ernet Protocol Version Multicast DNS Domain IPv4 and IPv6 local IPv4 254.169.in-addr.arpa IPv6 8.e.f.ip6.arpa IPv6 9.e.f.ip6.arpa IPv6 a.e.f.ip6.arpa IPv6 b.e.f.ip6.arpa SMPTE ST 2071-3:2014 Page 6 of 37 Pages 5 DNS-Based Service Discovery (DNS-SD) MDC Discovery shall be an extension of DNS-Based Se

48、rvice Discovery (DNS-SD) RFC 6763 with additional steps defined to allow for the use of DNS name servers that are not part of the networks primary naming infrastructure. DNS-Based Service Discovery (DNS-SD) allows MDC Discovery to operate using well-understood, mature technologies that have numerous

49、 implementations and a wide variety of available resources, such as books, white papers, third party libraries, coding examples, and human resources. The use of DNS further allows MDC Discovery to operate within an Internet Protocol network without the need for additional equipment, services, or expertise; providing scalability from two directly connected devices up to the Internet and everything in between. MDC Discovery processes may use DNS servers that are not part o