UPnP设备架构2.0规范详解

需积分: 5 131 浏览量更新于2024-07-09 收藏 1.89MB PDF 举报

"UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf 是一份关于UPnP（通用即插即用）设备架构2.0的最新规范文档，修订日期为2020年4月17日。这份文档包含了对UPnP 2.0协议的详细描述，特别是与NAT（网络地址转换）相关的部分。文档的某些部分是在UPnP论坛并入开放连接基金会之前完成的，因此可能受到UPnP论坛成员协议的法律约束。文档中的所有内容仅供学习和参考，不授予任何知识产权许可，并且明确声明不承担任何明示或暗示的保证。" UPnP（通用即插即用）是一种网络协议，旨在简化家庭和小型办公室的网络设备自动配置、发现和控制。UPnP 2.0是这一协议的最新版本，它扩展了1.0版的功能，以适应不断变化的网络环境和技术需求。 1. **设备架构**：UPnP设备架构定义了设备如何在网络上自我宣告、被发现和控制。它包括设备模型、服务模型和事件通知机制，使得不同厂商的设备能无缝协作。 2. **设备模型**：UPnP设备由一个或多个设备类型组成，每个设备类型都有一组相关功能的服务。设备通过XML描述文件（称为UDN，唯一设备名称）来定义其身份和能力。 3. **服务模型**：服务是设备提供的可操作功能的抽象，通常通过SOAP（简单对象访问协议）进行通信。服务具有状态变量、方法和事件，允许其他设备或控制点对其进行控制和监控。 4. **NAT穿透**：在UPnP 2.0中，NAT穿透是核心功能之一，它允许内部网络中的设备自动配置端口映射，以便外部设备可以访问内网服务。这对于多玩家在线游戏、远程桌面访问和家庭自动化等应用至关重要。 5. **事件通知**：当设备或服务的状态发生变化时，UPnP使用SSDP（简单服务发现协议）和HTTP推送事件来通知网络中的其他设备，确保网络内的实时同步。 6. **安全性考虑**：随着网络安全问题日益严重，UPnP 2.0在设计时考虑了安全因素，如加强的身份验证和加密机制，以及对潜在漏洞的修复。 7. **兼容性**：UPnP 2.0设计的目标是向下兼容早期版本，允许旧设备与新设备共存并交互。 8. **API和控制点**：UPnP 2.0提供了一套API，允许开发者创建控制点应用程序，这些应用程序能够发现、控制和监视网络上的UPnP设备。 9. **文档更新**：由于修订日期为2020年4月17日，这个文档可能包含了自2015年2月20日后的一些更新和改进，例如对新设备类型的支持、性能优化或者安全增强。 10. **法律免责声明**：文档明确指出，其内容仅供参考，不构成知识产权的授权，用户在使用文档信息时需自行承担风险，开发者和作者不对文档内容的准确性、可靠性或适用性做出任何保证。 "UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf"是理解UPnP 2.0协议的关键资料，对于网络设备开发者、智能家居集成商以及网络管理人员来说具有很高的价值。

— 15 —

Defined by a UPnP Forum working committee. One-to-one relationship with standard service

types. For more information, see clause 2, “Description”.

UPnP Device Schema

Defines the elements and attributes used in UPnP Device and Service Templates. Written in

XML syntax and derived from XML Schema (Part 1: Structures, Part 2: Datatypes). Defined by

the UPnP Device Architecture herein. For more information, see clause 2, “Description”.

Vendor Domain Name

A domain name that is supplied by a vendor. It is owned by the vendor, and shall be

registered with an ICANN accredited Registrar, such that it is unique. The vendor shall keep

the domain name registration up to date. A Vendor Domain Name length should be chosen to

be compatible with the use of the domain name in the UDA.

References and resources

RFC 2710, Multicast Listener Discovery for IPv6. Available at:

http://www.ietf.org/rfc/rfc2710.txt.

RFC 2616, HTTP: Hypertext Transfer Protocol 1.1. Available at:

http://www.ietf.org/rfc/rfc2616.txt.

RFC 2279, UTF-8, a transformation format of ISO 10646 (character encoding). Available at:

http://www.ietf.org/rfc/rfc2279.txt.

XML, Extensible Markup Language. W3C recommendation. Available at:

http://www.w3.org/XML/.

DEVICEPROTECTION, UPnP Device Protection specification. Available at

http://upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service.pdf.

Each clause in this document contains additional information about resources for specific

topics.

0 Addressing

Addressing is Step 0 of UPnP networking. Through addressing, devices and control points get

a network address. Addressing enables discovery (Step 1) where control points find

interesting device(s), description (Step 2) where control points learn about device capabilities,

control (Step 3) where a control point sends commands to device(s), eventing (Step 4) where

control points listen to state changes in device(s), and presentation (Step 5) where control

points display a user interface for device(s).

The foundation for UPnP networking is IP addressing. A UPnP device or control point is

allowed to support IP version 4-only, or both IP version 4 and IP version 6. This clause, and

the examples given throughout clauses 1 through 5 of this document, assumes an IPv4

implementation. Annex A of this document describes IPv6 operation. Each UPnP device or

control point which does not itself implement a DHCP server shall have a Dynamic Host

Configuration Protocol (DHCP) client and search for a DHCP server when the device or

control point is first connected to the network (if the device or control point itself implements a

DHCP server, it allowed to allocate itself an address from the pool that it controls). If a DHCP

server is available, i.e., the network is managed; the device or control point shall use the IP

address assigned to it. If no DHCP server is available, i.e., the network is unmanaged; the

device or control point shall use automatic IP addressing (Auto-IP) to obtain an address.

Auto-IP (defined in RFC 3927) defines how a device or control point: (a) determines if DHCP

is unavailable, and (b) intelligently chooses an IP address from a set of link-local IP

addresses. This method of address assignment enables a device or control point to easily

move between managed and unmanaged networks.

— 16 —

This clause provides an overview of the basic operation of Auto-IP. The operations described

in this clause are detailed and clarified in the reference documents listed below. Where

conflicts between this document and the reference documents exist, the reference document

always takes precedence.

0.1 Determining whether to use Auto-IP

A device or control point that supports Auto-IP and is configured for dynamic address

assignment begins by requesting an IP address via DHCP by sending out a DHCPDISCOVER

message. The amount of time this DHCP Client listens for DHCPOFFERs is implementation

dependent. If a DHCPOFFER is received during this time, the device or control point shall

continue the process of dynamic address assignment. If no valid DHCPOFFERs are received,

the device or control point shall then auto-configure an IP address using Auto-IP.

0.2 Choosing an address

To auto-configure an IP address using Auto-IP, the device or control point uses an

implementation dependent algorithm for choosing an address in the 169.254/16 range. The

first and last 256 addresses in this range are reserved and shall NOT be used.

The selected address shall then be tested to determine if the address is already in use. If the

address is in use by another device or control point, another address shall be chosen and

tested, up to an implementation dependent number of retries. The address selection shall be

randomized to avoid collision when multiple devices or control points are attempting to

allocate addresses. The device or control point chooses an address using a pseudo-random

algorithm (distributed over the entire address range from 169.254.1.0 to 169.254.254.255) to

minimize the likelihood that devices or control points that join the network at the same time

will choose the same address and subsequently choose alternative addresses in the same

sequence when collisions are detected. This pseudo-random algorithm should be seeded

using the device’s or control point’s Ethernet hardware MAC address.

0.3 Testing the address

To test the chosen address, the device or control point shall use an Address Resolution

Protocol (ARP) probe. An ARP probe is an ARP request with the device or control point

hardware address used as the sender's hardware address and the sender's IP address set to

0s. The device or control point shall then listen for responses to the ARP probe, or other ARP

probes for the same IP address. If either of these ARP packets is seen, the device or control

point shall consider the address in use and try a different address. The ARP probe is allowed

to be repeated for greater certainty that the address is not already in use; it is recommended

that the probe be sent four times at two-second intervals.

After successfully configuring a link-local address, the device or control point shall send two

gratuitous ARPs, spaced two seconds apart, this time filling in the sender IP address. The

purpose of these gratuitous ARPs is to make sure that other hosts on the net do not have

stale ARP cache entries left over from some other host that may previously have been using

the same address.

Devices and control points that are equipped with persistent storage are allowed to record the

IP address they have selected and on the next boot use that address as their first candidate

when probing, in order to increase the stability of addresses and reduce the need to resolve

address conflicts.

Address collision detection is not limited to the address testing phase, when the device or

control point is sending ARP probes and listening for replies. Address collision detection is an

ongoing process that is in effect for as long as the device or control point is using a link-local

address. At any time, if a device or control point receives an ARP packet with its own IP

address given as the sender IP address, but a sender hardware address that does not match

its own hardware address, then the device or control point shall treat this as an address

collision and shall respond as described in either a) or b) below:

— 17 —

a) Immediately configure a new link-local IP address as described above; or,

b) If the device or control point currently has active TCP connections or other reasons to

prefer to keep the same IP address, and has not seen any other conflicting ARP packets

recently (e.g., within the last ten seconds) then it is allowed to elect to attempt to defend

its address once, by recording the time that the conflicting ARP packet was received, and

then broadcasting one single gratuitous ARP, giving its own IP and hardware addresses

as the source addresses of the ARP. However, if another conflicting ARP packet is

received within a short time after that (e.g., within ten seconds) then the device or control

point shall immediately configure a new Auto-IP address as described above.

The device or control point shall respond to conflicting ARP packets as described in either a)

or b) above; it shall NOT ignore conflicting ARP packets. If a new address is selected, the

device or control point shall cancel previous advertisements and re-advertise with the new

address.

After successfully configuring an Auto-IP address, all subsequent ARP packets (replies as

well as requests) containing an Auto-IP source address shall be sent using link-level

broadcast instead of link-level unicast, in order to facilitate timely detection of duplicate

addresses.

0.4 Forwarding rules

IP packets whose source or destination addresses are in the 169.254/16 range shall NOT be

sent to any router for forwarding. Instead, the senders shall ARP for the destination address

and then send the packets directly to the destination on the same link. IP datagrams with a

multicast destination address and an Auto-IP source address shall NOT be forwarded off the

local link. Devices and control points are allowed to assume that all 169.254/16 destination

addresses are on-link and directly reachable. The 169.254/16 address range shall not be

subnetted.

0.5 Periodic checking for dynamic address availability

A device or control point that has auto-configured an IP address shall periodically check for

the existence of a DHCP server. This is accomplished by sending DHCPDISCOVER

messages. How often this check is made is implementation dependent, but checking every 5

minutes would maintain a balance between network bandwidth required and connectivity

maintenance. If a DHCPOFFER is received, the device or control point shall proceed with

dynamic address allocation. Once a DHCP assigned address is in place, the device or control

point is allowed to release the auto-configured address, but is also allowed to choose to

maintain this address for a period of time (or indefinitely) to maintain connectivity.

To switch over from one IP address to a new one, the device should, if possible, cancel any

outstanding advertisements made on the previous address and shall issue new

advertisements on the new address. The clause on Discovery explains advertisements and

their cancellations. In addition, any event subscriptions are deleted by the device (see clause

on Eventing).

For a multi-homed device with multiple IP addresses, to switch one of the IP addresses to a

new one, the device should cancel any outstanding advertisements made on the previous IP

address, and shall issue new advertisements on the new IP addresses. Furthermore, it shall

also issue appropriate update advertisements on all unaffected IP addresses. The clause on

Discovery explains advertisements, their cancellations and updates. The clause on Eventing

explains the effect on event subscriptions.

0.6 Device naming and DNS interaction

Once a device has a valid IP address for the network, it can be located and referenced on that

network through that address. There may be situations where the end user needs to locate

and identify a device. In these situations, a friendly name for the device is much easier for a

human to use than an IP address. If a device chooses to provide a host name to a DHCP

— 18 —

server and register with a DNS server, the device should either ensure the requested host

name is unique or provide a means for the user to change the requested host name. Most

often, devices do not provide a host name, but provide URLs using literal (numeric) IP

addresses.

Moreover, names are much more static than IP addresses. Clients referring a device by name

don't require any modification when the IP address of a device changes. Mapping of the

device's DNS name to its IP address could be entered into the DNS database manually or

dynamically according to RFC 2136. While devices supporting dynamic DNS updates can

to register DNS records on behalf of these DHCP clients.

0.7 Name to IP address resolution

A device that needs to contact another device identified by a DNS name needs to discover its

IP address. The device submits a DNS query according to RFC1034 and 1035 to the pre-

configured DNS server(s) and receives a response from a DNS server containing the IP

address of the target device. A device can be statically pre-configured with the list of DNS

servers. Alternatively a device could be configured with the list of DNS server through DHCP,

or after the address assignment through a DHCPINFORM message.

0.8 References

RFC1034, Domain Names - Concepts and Facilities. Available at:

http://www.ietf.org/rfc/rfc1034.txt.

RFC1035, Domain Names - Implementation and Specification. Available at:

http://www.ietf.org/rfc/rfc1035.txt.

RFC 2131, Dynamic Host Configuration Protocol. Available at:

http://www.ietf.org/rfc/rfc2131.txt.

RFC 2136, Dynamic Updates in the Domain Name System. Available at:

http://www.ietf.org/rfc/rfc2136.txt.

RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses. Available at:

http://www.ietf.org/rfc/rfc3927.txt.

1 Discovery

Discovery is Step 1 in UPnP™ networking. Discovery comes after addressing (Step 0) where

devices get a network address. Through discovery, control points find interesting device(s).

Discovery enables description (Step 2) where control points learn about device capabilities,

control (Step 3) where a control point sends commands to device(s), eventing (Step 4) where

control points listen to state changes in device(s), and presentation (Step 5) where control

points display a user interface for device(s).

Discovery is the first step in UPnP networking. When a device is added to the network, the

UPnP discovery protocol allows that device to advertise its services to control points on the

network. Similarly, when a control point is added to the network, the UPnP discovery protocol

allows that control point to search for devices of interest on the network. The fundamental

exchange in both cases is a discovery message containing a few, essential specifics about

the device or one of its services, e.g., its type, universally unique identifier, a pointer to more

detailed information and optionally parameters that identify the current state of the device.

剩余196页未读，继续阅读

jimte_pro

粉丝: 4485
资源: 11

UPnP设备架构2.0规范详解

UPnP Device Architecture

upnp2.0英文文档

UPnP-arch-DeviceArchitecture-v2.0

UPnP-arch-DeviceArchitecture-v1.1.pdf

UPnP-arch-DeviceArchitecture-v1.0.pdf

cacti-plugin-arch-2.0.tar.gz

OBJC-APP-Arch.pdf

sg-010-contrail-networking-arch-guide.pdf

.arch悦作业答题卡扫描工具V2.0.1022.exe

Comcast-SP-NGOD-GEN-ARCH-103-100731.pdf

最新资源