RE: Understanding WS-Discovery operational modes - WS-D Primer

Hi Alain,

 

Thanks for taking
time to review the document. Following are some of the high level points that
address many of your concerns listed below. 

 

* The ad-hoc
and managed mode are characterized by the MEPs used for the discovery of
services. For example, an actor say a Target Service; is in an ad-hoc mode if
it sends multicast Hello, Bye, listens for multicast Probe and Resolve. A
Target Service is in a managed mode if it sends unicast Hello and Bye. A client
is in an ad-hoc mode if it sends multicast Probe, Resolve and listens to
multicast Hello and Bye. It is in a managed mode if it sends unicast Probe and
Resolve.

 

* The
operational modes per actor are not mutually exclusive. For example, a Target
Service can be in an ad-hoc mode and a managed mode at the same time. Additionally,
various actors on a physical network can be in operating in different modes. 

 

Please find additional
comments below.

 

Thanks,

Vipul

 

 

 

From: Alain Regnier
[mailto:] 

Sent: Saturday, October 11, 2008 3:24 AM

To: 

Subject: RE: [ws-dd] Understanding WS-Discovery operational modes - WS-D
Primer

 

Hi Vipul,

 

thanks
for the document.

 

Following
are some questions/feedback on the WS-D Primer.

 

--

 

1.2.1
“. In this mode the protocol messages are sent multicast on the network.
“

Not all the protocol messages are sent multicast on the network in ad-hoc
discovery mode. ProbeMatch and ResolveMatch are sent unicast. It would be more
appropriate to say protocol messages are sent multicast to Target Service.

 

[vipul] Agree,
not all messages are sent multicast. 

 

Figure 3 – The scenario illustrated in this diagram does not quite fit
the scope defined by ws-discovery, or seem practical in real world. DP acts
more like proxy defined in ws-discovery remote extension document.

[vipul] The
scenario is illustrating one of the high level point I mentioned above, i.e. a
Target Service can be in more than one mode at the same time depending upon its
configuration. 

 

Figure
4: This figure shows a client receiving unicast Hello: it should probably be
mentioned in the bullet points above the figure, since it is not strictly
ad-hoc mode messages, or removed and placed in section 3.3 instead.

 

[vipul] This is
a multicast suppression Hello that a Client operating in an ad hoc mode
receives from a Discovery Proxy.

 

2.2 the
agent mentioned in this section should be described with more details

 

 

section 4 Discovery Proxy

"Additionally it can be configured to act as a multicast suppression
agent"

According to 1.1 (and in a lot of people's mind) it is the first of three
things that a DP does (or the main thing a DP does). That's why this sentence
doesn't seem to be a good choice. (it make it sounds like it's an additional
benefit, instead of a core benefit)

 

[vipul] Agree,
that this can be reworded better. At a high level there are two main functionalities
of a Discovery Proxy. 

1.       Support discovery in a managed mode 

2.       Suppress multicast on an ad hoc network
by redirecting the traffic to its managed endpoint. 

 

There are scenarios for both functionality. For example, for an
enterprise service registry in a data center it does not make sense to
participate in a multicast suppression as there may not be any multicast
traffic in the data center for the services it represents.

 

There
should be a section about security, and particularly things like man in the
middle attacks

 

[vipul] The goal of the
primer right now is to get us on the same page with respect to operation modes
of discovery; as a stepping stone for the managed mode cluster proposal.

Is Managed Mode applied uniformly to all Target Services, Clients and Discovery
Proxies on a network? If so it should be mentioned as such. If not, then a DP
can be in Managed Mode and a TS/Client may not be, and therefore the DP can
receive multicast Hellos/Byes/Probes/Resolves, and that should be indicated in
Figure 7.

 

[vipul] As I
mentioned earlier on a physical network different actors can be in different
mode. One actor can be in more than one mode at the same time.

Section
4.2: What is the wsd:Types of a Discovery Proxy when it advertises itself?

 

[vipul] d:DiscoveryProxy.

Section
4.2, line 145-147: “It then offers the Clients to query this information
via managed mode….” Does this mean the DP running in ad-hoc mode
can let Clients query it as if in managed mode? Does this mean DP is converting
itself to ad-hoc mode, or just that Clients get converted to managed mode and
DP stay in ad-hoc mode?

 

[vipul] Conceptually
a Discovery Proxy that is suppressing multicast has two endpoints,

1.             A
managed endpoint that is operating in a managed mode (managed mode MEP). 

2.             An
ad hoc endpoint that is operating in an ad hoc mode that does multicast
suppression and redirect the clients to the managed endpoint. 

 

The proxy is
operating in both modes and continue to do so. If Clients sends multicast
Probe/Resolve, the proxy receives this through the ad hoc endpoint and try to
suppress it by sending unicast Hello that contains information about managed
endpoint. The client upon receiving this information switches to the managed
mode and sends messages to the managed endpoint of the proxy.

5.1.
Typo in step 12: Target Service 2 is projector, not scanner.

 

[vipul] Good
catch. Thanks.

line
147: it could be helpful to clarify what exactly is the "managed mode
endpoint"

 

[vipul] Ok, in
this context it is an endpoint of a Discovery Proxy that supports managed mode
message exchange pattern (or d:DiscoveryProxy).

 

Line 150-154: This bullet point should clarify that the Probe the DP is
listening for is a Probe for DP wsd:Types, not a Probe for TargetServices 

 

[vipul] Agree.

 

Figure
9: the figure is difficult to read... it could help if the numbers were
ordered.

 

[vipul] I know
it has a lot of information, I tried best to have relevant information and yet
fit it in one page.  The point that this is illustrating is that Target
Services that operate in an ad-hoc mode are unaffected by the presence of a Discovery
Proxy that does multicast suppression and continue to operate normally. 

 

- if a service gets aware of the presence of a DP on the network (for example
through DHCP) should it switch to managed mode and talk only to this DP
(through unicast)?

 

[vipul] This is
up to a service implementation. The protocol defines the message exchanges in each
mode for all of the roles. For each implemented mode and role the protocol
exchanges must follow the specification. A higher level profile for example in
this case DPWS can define requirement and conditions to operate in a particular
mode.

 

- How can a client be sure that DP always provides up-to-date information of
all the TARGET SERVICE, for instance, what if a DP responds to a client’s
Probe, but not to a TARGET SERVICE’s Hello? 

 

[vipul] If a DP
does not have information about a Target Service it should not be doing
multicast suppression. This would be an implementation issue.

 

- How can a Target Service verify whether DP is responsive? In managed mode, a
TARGET SERVICE sends unicast Hello to a DP once its metadata has been changed.
If a DP is not responsive, a TARGET SERVICE has to send multicast Hello. 

 

 [vipul] If a Target
Service is using HTTP, it can determine the responsiveness by loss of a
HTTP/TCP connection. A service can operate in an ad hoc mode and a managed mode
at the same time or as you described may switched from managed to ad hoc mode,
but this would be determined by the implementation support and configuration of
the service.

- How can a Target Service opt not to be presented by a DP?

 

[vipul] A
Target Service can opt to not operate in a managed mode and send information to
DP. In an ad hoc mode a Target Service multicast its information so it does not
have any control over who uses this information. 

 

- Is there any difference between a DP and a proxy as defined in ws-discovery
remote extension?

 

The
document assumes that a Service needs to know in advance what a DP is,
preventing a seemless integration.

Some people assume that a DP should be a component that is inserted in an
existing network, mainly to suppress multicast. (ie the Service, including
those services that are already shipping, don't even need to know they are
talking to a DP) Some think it should help cross network communications in
secure/internal environment.

We
may need a broader discussion about the expected goals of a Discovery Proxy...

A way to deal with it would be to define several "levels" of DP: a
first level would be a seemless multicast suppression (useful in trusted
environments for example), and a second level would be a more complex DP as
defined in this document, and requiring several changes to services.

[vipul] I agree
with the requirement you mentioned about seamless integration in an ad hoc
mode. The document isn’t making any assumptions otherwise If you
introduce a discovery proxy that does multicast suppression to an ad hoc
network, the Target Services would not change. The proxy would obtain
information about the Target Services on the network by sending multicast Probe
and listening for multicast Hello/Bye. It would then suppress the clients on a
ad hoc network and redirect them to managed mode.

 

--

 

 

Alain

 

 

 

 

 

 

From: Vipul Modi
[mailto:]

Sent: Mon 10/6/2008 5:18 PM

To: 

Subject: [ws-dd] Understanding WS-Discovery operational modes - WS-D
Primer

Hello all,

 

During the first face to face, some of us felt
that the current WS-Discovery specification does not provide a
clear description of requirements and responsibilities of various actors in an
ad hoc mode and a managed mode. We made good progress on this during the
technical discussions and white boarded our understanding of the specification
in this regard. We filed and accepted a number of issues called “managed
cluster” in this regard. 

 

Please find the attached document titled “WS-Discovery
Primer” that captures the essence of our discussions and understanding,
and explains the behavior of a Target Service, a Client and a Discovery Proxy
in a managed mode and an ad hoc mode as defined by the current specification.
This document should allows us to be on the same page with respect to
understanding ad hoc and managed modes and message exchanges in these modes,
and help us make progress on the “managed cluster” issues.

 

Thanks,

Vipul Modi

Senior Development Lead,
Microsoft Corporation. 

 |
425-707-2402