Remote Administration via DLS within NAT environments (DCMP) - Revision history

Horemu at 00:02, 22 April 2011

2011-04-22T00:02:19Z

Horemu: /* Short Overview */

2010-09-29T08:20:55Z

‎Short Overview

Horemu: /* Short Overview */

2010-09-28T14:35:13Z

‎Short Overview

Horemu: /* What is the Problem? */

2010-09-28T14:33:05Z

‎What is the Problem?

Horemu: /* What is the Problem? */

2010-09-28T14:05:34Z

‎What is the Problem?

Horemu: /* Solution Overview */

2010-09-28T13:57:12Z

‎Solution Overview

Horemu: /* Solution Overview */

2010-09-28T13:56:19Z

‎Solution Overview

Horemu: /* Solution Overview */

2010-09-28T12:42:55Z

‎Solution Overview

Horemu: /* Device Requirements */

2010-09-28T12:35:38Z

‎Device Requirements

Horemu: /* Device Requirements */

2010-09-28T12:34:55Z

‎Device Requirements

← Older revision		Revision as of 00:02, 22 April 2011
Line 1:		Line 1:
		+	{{Breadcrumb\|0\|0\|{{dev-en}}\|OpenStage}}
	{{OS-FD-Access}}{{FD-Sytematics-Box		{{OS-FD-Access}}{{FD-Sytematics-Box
	\| family = {{FD-Cat\|OpenStage}}		\| family = {{FD-Cat\|OpenStage}}

@@ Line 20: / Line 20: @@
 However, in the case of DLS-driven events (E.g. pending jobs regarding configuration changes, SW deployment, file deployment), there must be the possibility for DLS to trigger the device to open a session.
-The existing mechanism is the so-called ''Contact-Me'' request, an HTTP request sent by DLS to the device. The URL that is used by DLS to initiate a ''Contact-Me'' request, is derived from the so-called ''con-tact-me-uri'', which is sent by the device to DLS at registration time:
+The existing mechanism is the so-called ''Contact-Me'' request, an HTTP request sent by DLS to the device. The URL that is used by DLS to initiate a ''Contact-Me'' request, is derived from the so-called ''contact-me-uri'', which is sent by the device to DLS at registration time:
 [[File:DLS Workpoint Interface (WPI).png]]<br />

← Older revision		Revision as of 14:35, 28 September 2010
Line 11:		Line 11:

	== Short Overview ==		== Short Overview ==
		+
		+	The DLS Workpoint Interface is based on an XML-based message exchange using HTTP over TLS (HTTPS) as transport protocol: the device (E.g. OpenStage) acts as client and initiates the message exchange by opening an HTTPS session to DLS. Sessions are opened due to specific device-driven events:
		+
		+	* the device restarts
		+	* a configuration change has been done on the device (via local display or web-based man-agement)
		+	* inventory changes of the device.
		+	* logon or logoff of a mobile user on a (DLS-mobility enabled) device
		+	However, in the case of DLS-driven events (E.g. pending jobs regarding configuration changes, SW deployment, file deployment), there must be the possibility for DLS to trigger the device to open a session.
		+
		+	The existing mechanism is the so-called ''Contact-Me'' request, an HTTP request sent by DLS to the device. The URL that is used by DLS to initiate a ''Contact-Me'' request, is derived from the so-called ''con-tact-me-uri'', which is sent by the device to DLS at registration time:
		+
		+	[[File:DLS Workpoint Interface (WPI).png]]<br />
		+	''DLS Workpoint Interface (WPI)''

	== What is the Problem? ==		== What is the Problem? ==

← Older revision		Revision as of 14:33, 28 September 2010
Line 20:		Line 20:

	Firewall(s) can be established between the network segment DLS is located and the network seg-ment(s), the devices are located. A typical configuration is that the devices are part of the customer LAN, while the DLS is located in a DMZ together with other administration and communication servers. Outgoing traffic from the DMZ (possibly maintained by a 3rd party company) into the customer LAN may not be allowed at all:		Firewall(s) can be established between the network segment DLS is located and the network seg-ment(s), the devices are located. A typical configuration is that the devices are part of the customer LAN, while the DLS is located in a DMZ together with other administration and communication servers. Outgoing traffic from the DMZ (possibly maintained by a 3rd party company) into the customer LAN may not be allowed at all:
		+
		+	[[File:WPI Problem 1 Firewall.png]]<br />
		+	''WPI Problem #1: Firewall''
		+
		+	Result: DLS is not capable to inform devices about pending DLS jobs.
		+
		+	=== Problem #2: Network Address Translation ===
		+
		+	Today we are seeing more and more residential users moving to VoIP. Many companies also have small branch offices located remotely and also wish to deploy IP phones at these remote sites.
		+	Both residential users and branch offices are typically protected from the WAN or Internet by a router or firewall.
		+
		+	The corporate router or firewall generally induces a network address translation (NAT) to ''hide'' the internal IP-Address from the outside network. This makes it impossible to connect from the WAN/Internet to a phone deployed inside the remote branch office because its IP-Address is not visible from the outside world. Similarly, if the IP phone is deployed at home in a residential scenario, the home router/firewall also induces a NAT.
		+
		+	This makes it impossible to ''see'' the IP phones remotely in order that they can be administered by DLS: the ''contact-me-uri'', which is sent by the device to DLS at registration time, contains the hidden IP-address, which is not addressable from the DLS' network location.
		+
		+	[[File:WPI Problem 2 NAT.png]]<br />
		+	''WPI Problem #2: NAT''
		+
		+	Result: Again, DLS is not capable to inform devices about pending DLS jobs.

	== Solution Overview ==		== Solution Overview ==

← Older revision		Revision as of 14:05, 28 September 2010
Line 13:		Line 13:

	== What is the Problem? ==		== What is the Problem? ==
		+
		+	Device-driven events can usually be performed without restrictions: devices act as HTTPS clients and contact the DLS, which is a HTTPS server listening on a specific IP Address/Port. Even in Carrier or Hosted Business environments, the DLS can be seen as just an additional Web Server that replies to requests from the Internet.
		+	The Contact-Me request however inverts the client and server roles, which has significant impact in the following scenarios.
		+
		+	=== Problem #1: Firewall ===
		+
		+	Firewall(s) can be established between the network segment DLS is located and the network seg-ment(s), the devices are located. A typical configuration is that the devices are part of the customer LAN, while the DLS is located in a DMZ together with other administration and communication servers. Outgoing traffic from the DMZ (possibly maintained by a 3rd party company) into the customer LAN may not be allowed at all:

	== Solution Overview ==		== Solution Overview ==

@@ Line 21: / Line 21: @@
 Devices that suffer from the problems described in the preceding chapters, need to be configured to poll the DCMP periodically by issuing an HTTP request that determines whether DLS needs to be con-tacted or not:
-[[File:DLS Contact-Me Proxy (DCMP).png]]
+[[File:DLS Contact-Me Proxy (DCMP).png]]<br />
 ''Solution: DLS Contact-Me Proxy (DCMP)''
@@ Line 29: / Line 29: @@
 For example:
-  http://dcmp-server:8080/dcmp/contact-me?device-id=0A:E8:F3:00:42:91
+  <nowiki>http://dcmp-server:8080/dcmp/contact-me?device-id=0A:E8:F3:00:42:91</nowiki>
 The decision criterion for the device is the HTTP return status code. The possible values are:

← Older revision		Revision as of 13:56, 28 September 2010
Line 20:		Line 20:

	Devices that suffer from the problems described in the preceding chapters, need to be configured to poll the DCMP periodically by issuing an HTTP request that determines whether DLS needs to be con-tacted or not:		Devices that suffer from the problems described in the preceding chapters, need to be configured to poll the DCMP periodically by issuing an HTTP request that determines whether DLS needs to be con-tacted or not:
		+
		+	[[File:DLS Contact-Me Proxy (DCMP).png]]
		+	''Solution: DLS Contact-Me Proxy (DCMP)''
		+
		+	The device polls the DCMP using a HTTP Request sent to the dcmp-url, which is obtained from the DLS. The device adds the parameter
		+	contact-me?device-id=<mac-addr>
		+	to the URL where ''<mac-addr>'' is the Device ID as registered to DLS (item ''mac-addr'').
		+
		+	For example:
		+	http://dcmp-server:8080/dcmp/contact-me?device-id=0A:E8:F3:00:42:91
		+
		+	The decision criterion for the device is the HTTP return status code. The possible values are:
		+
		+	* '''200 OK''' – No pending DLS jobs, a DLS session does not need to be opened
		+	* '''202 ACCEPTED''' – Pending DLS jobs available, the device should open a DLS session using the ReasonForContact = solicited
		+	Two parameters are required for that purpose and can be set by DLS individually per device:
		+	* the DCMP URL to be called
		+	* the poll interval

	== Device Requirements ==		== Device Requirements ==

← Older revision		Revision as of 12:42, 28 September 2010
Line 15:		Line 15:

	== Solution Overview ==		== Solution Overview ==
		+
		+	To solve the Firewall/Nat traversal problems a DLS Contact-Me Proxy (DCMP) is deployed on a server in the same DMZ / location as the DLS server and has similar requirements to the connectivity as the XML-message part of the DLS Interface:
		+	* Allow incoming HTTP requests from any location where devices are installed that need to con-tact the DLS.
		+
		+	Devices that suffer from the problems described in the preceding chapters, need to be configured to poll the DCMP periodically by issuing an HTTP request that determines whether DLS needs to be con-tacted or not:

	== Device Requirements ==		== Device Requirements ==

@@ Line 19: / Line 19: @@
 * Configuration of DCMP URL and poll interval via DLS. Note: the ''Contact-Me'' is still mandatory and to be supported in any case (and always ''active'', independent of the device's DCMP configuration). Their current value need not to be stored persistently on the device: every restart of the device leads to a startup-request to DLS, where the current valid settings of these items are obtained.
-* Execute poll requests at the required interval (in addition to listening on contact-me) and check HTTP return status code. The status code ''202 ACCEPTED'' indicates that pending DLS jobs are available. The device should open a DLS session using the ReasonForContact = solicited.
+* Execute poll requests at the required interval (in addition to listening on contact-me) and check HTTP return status code. The status code ''202 ACCEPTED'' indicates that pending DLS jobs are available. The device should open a DLS session using the ReasonForContact = solicited. Note: Any contact to DLS (e.g. due to device start-up, local-changes, inventory-changes, etc.) should restart the timer for the DCMP poll interval
 == Data ==