ANSI CTA-852-C-2014 Tunneling Device Area Network Protocols Over Internet Protocol Channels (Formerly ANSI CEA-852-C).pdf

《ANSI CTA-852-C-2014 Tunneling Device Area Network Protocols Over Internet Protocol Channels (Formerly ANSI CEA-852-C).pdf》由会员分享，可在线阅读，更多相关《ANSI CTA-852-C-2014 Tunneling Device Area Network Protocols Over Internet Protocol Channels (Formerly ANSI CEA-852-C).pdf（66页珍藏版）》请在麦多课文档分享上搜索。

1、 ANSI/CEA Standard Tunneling Device Area Network Protocols over Internet Protocol Channels ANSI/CEA-852-C April 2014 NOTICE Consumer Electronics Association (CEA) Standards, Bulletins and other technical publications are designed to serve the public interest through eliminating misunderstandings bet

2、ween manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards, Bulletins and other technical publications shall not in a

3、ny respect preclude any member or nonmember of CEA from manufacturing or selling products not conforming to such Standards, Bulletins or other technical publications, nor shall the existence of such Standards, Bulletins and other technical publications preclude their voluntary use by those other tha

4、n CEA members, whether the standard is to be used either domestically or internationally. Standards, Bulletins and other technical publications are adopted by CEA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, CEA does not assume any liability to a

5、ny patent owner, nor does it assume any obligation whatever to parties adopting the Standard, Bulletin or other technical publication. This document does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user

6、 of this document to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. This document is copyrighted by the Consumer Electronics Association (CEA) and may not be reproduced, in whole or part, without written permission. Fede

7、ral copyright law prohibits unauthorized reproduction of this document by any means. Organizations may obtain permission to reproduce a limited number of copies by entering into a license agreement. Requests to reproduce text, data, charts, figures or other material should be made to CEA. (Formulate

8、d under the cognizance of the CEA R7 Home Networks Committee.) Published by CONSUMER ELECTRONICS ASSOCIATION 2014 Technology Phone: 800-854-7179; Fax: 303-397-2740; Internet: http:/; E-mail: . IETF Documents: Internet Engineering Task Force (IETF) Secretariat, c/o Corporation for National Research I

9、nitiatives, 1895 Preston White Drive, Suite 100, Reston, VA 20191-5434, USA; (703) 620-8990 / (703) 620-9071 (FAX); URL: www.ietf.org, IETF RFCs may be downloaded from www.ietf.org/rfc.html, IETF Internet drafts may be downloaded from www.ietf.org/ID.html 3 Introduction This document provides specif

10、ications for the transporting of Component Network (CN) packets over Internet Protocol (IP) networks using a tunneling mechanism wherein the CN packets are encapsulated within the IP packets. It applies to both CN nodes and CN routers. The purpose of this specification is to insure interoperability

11、between various CN devices that wish to use IP networks to communicate using a particular CN protocol. The specification is intended to be general enough to handle a wide range of CN protocols. In particular this specification will cover the following standard CN protocols: ANSI/CEA-709.1-D 2. CEA-6

12、00 CEBus 11. The main body of this specification is independent of the CN protocol being transported over the IP network. The reader is directed to Annex A and Annex B for the normative and informative, respectively, aspects of this specification that are specific to ANSI/CEA-709.1-D. Likewise Annex

13、 C and Annex D are the normative and informative, respectively, aspects of this specification as they apply to CEA-600 CEBus. Figure 1 shows a possible configuration of such CN devices and networks connected to an IP network. CEA-852-C 6 Figure 1 Typical CN/IP Application Figure 1 depicts two types

14、of CN devices: CN nodes and CN routers. Note that the routers shown can route packets between typical CN channels (such as twisted pair or power line) and an IP channel or it can route CN packets between two IP channels. In this document the IP channel will be defined in such a way to allow it to be

15、 used like any other CN channel. In the above diagram the IP network can be considered to be one or more IP channels. This specification covers only how CN packets are transported over IP channels. It does not cover how CN packets are routed between standard CN channels and IP channels. This specifi

16、cation is not intended to cover the lower layers (physical, MAC and link) layers of either standard CN or IP channels. 4 Requirements The following is a set of general requirements for the transporting of CN packets over IP channels: Be as efficient as possible to allow quasi Realtime operation. Be

17、independent of the application level interface used to receive the packets. For example the tunneling protocol should not rely on the existence of a socket interface or how that interface may be used. Insure that CN packet ordering is preserved. Insure that CN packets that are “stale” (outside the m

18、aximum timeout characteristics of the IP channel) are not forwarded. Detect packets that get duplicated in the IP network. Support IP routing devices that prioritize IP packets. Optional security measures to prevent malicious users from tampering with devices. Scalable. Allow status information to b

19、e extracted from CN/IP devices. CN/IP Router CN Channel CN Nodes CN/IP Router CN Channel CN Nodes CN/IP Router CN Channel CN Node INTERNET IP Channel IP Channel Workstation running CN Stack Embedded CN Device CN/IP to CN/IP Router CN/IP to CN/IP Router CEA-852-C 7 Support the exchange of configurati

20、on information between CN/IP devices and configuration servers. 5 CN/IP Device Specification 5.1 IP Related Device Specifications A CN/IP device MUST behave like any standard IP host capable of exchanging IP packets with any other IP host either on the same IP subnet or anywhere else in the Internet

21、 cloud. A CN/IP device MUST have a single uni-cast IP address and MAY be capable belonging to as many as 32 multi-cast groups. It is OPTIONAL that a CN/IP device support multi-casting. This document does not address the routing of IP packets between subnets or through the Internet. The CN/IP devices

22、 MUST be compatible with whatever standard mechanisms (IP routers, switches, etc.) are required to perform the IP routing functions. 5.2 CN Related Device Specifications 5.2.1 Packet Formats The general format of CN packets which are tunneled over the IP channel are those packets that are received f

23、rom or sent to the Link layer (layer 2) of the CN protocol stack. Refer to Annex A (ANSI/CEA-709.1-D Normative) and Annex C (CEA-600 Normative) for a precise specification of the packet formats corresponding to specific CN protocols. Link layer packets are called LPDUs in the OSI protocol stack form

24、alism. 5.2.2 Addressing Schemes Different CN protocols generally use different addressing schemes to exchange packets. Although it is generally not necessary to understand the contents of a CN packet or its addresses in order to tunnel CN packets over IP, some aspects of the CN addressing scheme are

25、 reflected in the process of configuration. This is especially true when it comes to setting up the IP channels that are used for tunneling. Since CN protocols use different addressing schemes the terminology used in the main body of this specification for describing addresses are meant to be genera

26、l and rich enough to describe the superset of addressing schemes used in all CN protocols. The following CN addressing terms are used in this specification. Unique ID. This refers to an ID that is globally unique to all devices within a specific protocol. Unique IDs are generally fixed in nature in

27、that they never change through the life of a device. Domain. This is the highest level of a three level hierarchical addressing scheme. Domain IDs should be unique within a particular network. This means that in a particular network where Domain is used if two devices have the same Domain ID they be

28、long to the same Domain. Domain IDs are generally logical in nature and can be changed and configured. Subnet. This is the middle level of a three level hierarchical addressing scheme. Subnet IDs should be unique within a particular domain. This means that in a particular network where subnet IDs ar

29、e used if two devices have the same Domain ID and the same Subnet ID then they belong to the same Subnet. Some CNs does not use Domains in which case the Subnet may be the highest level of address for a device. Subnet IDs are generally logical in nature and can be changed and configured. Node. This

30、is the lowest level of any hierarchical addressing scheme. Node IDs should be unique within a particular Subnet. No two devices within the same subnet should have the same Node ID. Node IDs are generally logical in nature and can be changed and configured. Group. Groups are an orthogonal addressing

31、scheme to the hierarchical Domain/Subnet/Node triplet just described. Groups are used to allow multi-casting of messages. Some CNs may not support group addresses and even those that do will have CEA-852-C 8 different rules for how they relate to the other addressing schemes. These considerations ar

32、e not relevant to this specification. The definitions above are fairly general and are provided as a guideline for how to map specific CN protocols to these terms. In general how the various addressing schemes work within a CN protocol is not relevant to this specification. It is only necessary to k

33、now what the various addressing terms refer to. Of special note is how these addresses are used for routing within a particular CN protocol. Some CN protocols support more routing functions than others. This is relevant because one of the optional configuration packets that can be exchanged include

34、routing information. For those CN protocols that do not support routing this message may simply not be supported or the addresses specified within the message appropriately limited. For each CN protocol supported in this specification a table is given in the appropriate appendix that specifies how t

35、he appropriate addresses used in that protocol map to the terms given above. 6 IP Channel Specification IP channels are not like typical CN channels that currently exist. Typical CN channels are physical busses by nature. This implies that all devices on the channel will by default receive all packe

36、ts transmitted on that channel. In addition when a new device is added to the channel it is not necessary that other devices on the channel become aware of it before they can exchange packets. To transmit a packet on a channel it is only necessary that a device be capable of physically transmitting

37、the packet on the channel, nothing more. If a device is simply physically connected to a channel it is capable of exchanging packets with other devices on the channel. By contrast an IP channel is not physical, but logical in nature. There are a number of different physical media that can support IP

38、 communications and any of them should be capable of supporting a CN channel. Because we are dealing with a logical channel it is necessary to “construct” the channel by informing each device on the channel of the existence of the other devices on that channel. In other words before a device can tra

39、nsmit a packet to some other device on an IP channel it must be made aware of how to specifically send a packet to that device, i.e. its IP address. Another significant difference between physical and logical channels is that in the case of typical physical channels it is possible to calculate fixed

40、 upper bounds on the length of time it will take a packet to traverse from one device to another once the packet is transmitted on the channel. This is not always possible for IP networks. The deviation of packet delivery times between CN devices on an IP channel are much higher than those experienc

41、ed with typical CN channels. As depicted in Figure 1 the IP channel is used as an intermediary transport mechanism for the CN packets by a variety of CN/IP devices. When a CN packet is transported on an IP channel, an IP message encapsulating the CN packets is sent to other CN/IP devices on that IP

42、channel. On reception of one of the IP messages by a CN/IP device the CN packets are extracted and processed. A single IP message may contain more than one CN packet. Therefore the IP messages must be formatted in such a way to allow the extraction of the individual CN packets. This is referred to a

43、 packet “aggregation”. CN/IP devices MUST support the reception of bunched packets. Likewise the aggregation MUST be done in such a fashion that each CN packet contained within a bunched IP message is complete, i.e. CN packets should not cross IP message boundaries as a result of aggregation. It is

44、also a requirement that intermediate IP devices be capable of unbundling bunched CN packets and aggregating them in a different manner before forwarding them. The IP channel is specified by the list of unique pairs. Each pair consists of a uni-cast IP host address and a uni-cast port, with exactly o

45、ne pair for each CN/IP device. Multiple devices may share the same host address but must have different ports. Conversely, multiple devices may all CEA-852-C 9 use the same port but must have different host addresses. Unfortunately, in the original specification the channel routing request packet di

46、d not include a field for the uni-cast port only the host address. Consequently, 852 channels with devices and/or servers that implement the original specification have the limitation that no two devices with the same host address may be on the same 852 channel even if they have different ports. Thi

47、s limitation has been removed in revision A of the specification. The updated channel routing request packet includes a uni-cast port field. There is no maximum to the number of CN/IP devices on a single IP channel. If every CN/IP device on an IP channel contained a list of uni-cast IP addresses for

48、 every other CN/IP device on that IP channel, this is all that would be required to enable the tunneling of CN packets. In the most brute force approach, for each CN packet to be forwarded on the IP channel a separate uni-cast IP message could be sent to each CN/IP device in the channel. This does n

49、ot scale very well, so the following techniques will be used to reduce the IP traffic: IP Multi-cast groups. Selective forwarding. IP multi-cast groups allow a single IP message to be sent to more than one CN/IP device. Therefore a complete definition of CN/IP channel should contain not only the uni-cast IP addresses of all the CN/IP devices on the channel but also the IP multi-cast groups to which they belong. Each CN/IP device can belong to up to 32 multi-cast addresses. Selective forwarding refers to examini