I read this carefully. Here are my comments.
Non-nits:
2.2.1 Endpoint Name Resolution Protocol
The name servers use a protocol called Endpoint Name Resolution
Protocol (ENRP) for communication with each other to make sure that
all have the same information about the server pools.
I'm concerned that this will spark a lengthy debate about synchronization of ENRP databases. We can't guarantee instantaneous updates of the database and a perfectly synchronized name space. How about something like:
The name servers use a protocol called Endpoint Name Resolution
Protocol (ENRP) for communication with each other to exchange information and updates
about the server pools.
2.2.2 Aggregate Server Access Protocol
ASAP in conjunction with ENRP provides a fault tolerant data transfer
mechanism over IP networks.
I'm concerned that this will be interpreted as a general feature with some sort of guarantee. It is only offered by use of specific services described in services document. In other words, this will imply that it offers transparent fail-over in all cases which is not true. Even with that, there is no guarantee of uninterrupted service. It is best effort. I would delete this sentence or talk about services and different possibilities. These are discussed in the services document.
In addition, ASAP defines each logical communication destination as a
server pool, providing full transparent support for server-pooling
and load sharing.
I don't understand this statement. What is a logical communication destination?
ASAP is also used by a server to join or leave a server pool. It
registers or deregisters itself by communicating with a name server,
which will normally the home NS.
see changes below:
ASAP is also used by a PE to join or leave a server pool. It
registers or deregisters itself by communicating with a name server,
which will normally be the home NS.
ASAP allows dynamic system
scalability, allowing the pool membership to change at any time
without interruption of the service.
Same concern as above. This is only offered by use of specific services described in services document. Even with that, there is no guarantee of uninterrupted service. It is best effort.
Nits:
1.1 Overview
This document defines an architecture, for providinge a highly
available reliable server function in support of some service. The
way this is achieved is by forming a pool of servers, each of which
is capable of supporting the desired service, and providing a name
service that
see changes below, misspelled words:
This document defines an architecture, for *providing* a highly
available reliable server function in support of a service or set of services.
This is achieved by forming a pool of servers, each of which
is capable of supporting the desired service(s), and providing a name
service that...
2.1 RSerPool Functional Components
Each server pool will be identifiable by a unique name which is
simply a byte string, called the pool handle.
see changes below:
Each server pool is identified by a unique name which is
simply a byte string, called the pool handle.
o A protocol field of the IP header specifying the transport layer
protocol or protocols.
see changes below:
o A protocol field specifying the transport layer
protocol or protocols.
Please note that the RSerPool architecture supports both IPv4 and
IPv6 addressing. A PE can also support multiple transport layers.
see changes below:
Note that the RSerPool architecture supports both IPv4 and
IPv6 addressing. A PE can also support multiple transport protocols.
2.2.1
ENRP employs a client-server
model with which an name server will respond to the name translation
service requests from endpoint clients running on the same host or
running on different hosts.
see changes below:
ENRP employs a client-server
model in which a name server will respond to the name translation
service requests from endpoint clients.
2.2.3 PU <-> NS Communication
The PU <-> NS communication is used for doing name queries.
see changes below:
The PU <-> NS communication is used for performing name queries.
2.2.4 PE <-> NS Communication
The PE <-> NS communication is used for registration and
deregistration of the PE in one ore more pools and for the
misspelled word:
The PE <-> NS communication is used for registration and
deregistration of the PE in one *or* more pools and for the
o Multiplexed data and control channel. Both channels are
transported over one transport connection. This can either be an
SCTP association, with data and control channel are seperated by
the PPID, or an TCP connection, with data and control channel
being handled by a TCP mapping layer.
misspelled word:
o Multiplexed data and control channel. Both channels are
transported over one transport connection. This can either be an
SCTP association, with data and control channel are *separated* by
the PPID, or an TCP connection, with data and control channel
being handled by a TCP mapping layer.
When a name server boots up a UDP multicast message may be sent out
for initial detection of other name servers in the operational scope.
The other name servers send an answer using a unicast UDP message.
Aren't we addressing multicast at a later time? If so, delete this paragraph. Otherwise, some nits:
When a name server initializes a UDP multicast message may be transmitted
for initial detection of other name servers in the operational scope.
The other name servers send a response using a unicast UDP message.
2.3.1
communication may not be know by the peer.
Providing information to which PE the OU should failover can also be
very important. Consider the scenario given in the following figure.
misspelled words:
communication may not be *known* by the peer.
Providing information to which PE the *PU* should failover can also be
very important. Consider the scenario *presented* in the following figure.
Figure 4
Two PE accessing the same PE
Should be:
Two PUs accessing the same PE
2.3.2 Cookies
Cookies may be sent from the PE to the PU if the PE wants to do this.
The PU only stores the last received cookie. In case of a fail over
it sends this last received cookie to the new PE.
some changes:
Cookies may optionally be sent from the PE to the PU.
The PU only stores the last received cookie. In case of fail over
the PU sends this last received cookie to the new PE.
[Editors note] This section has not been updated. The examples will
be updated after the architecture has been finalized.
Please delete this.
3.1
After figure 8:
1. the Signaling Gateway (SG) receives an incoming signaling message
to be forwarded to the GWC. SG(X)'s ASAP layer would send an ASAP
request to its "local" NS to request the list of pool elements
(PE's) of GWC (using (a)). The key used for this query is the
pool handle of the GWC. The ASAP layer queues the data to be sent
in local buffers until the NS responds.
Don't use the word "key" for this as it sounds like some security key. Use bit string or some other phrase.
some change:
The bit string used for this query is the
pool handle of the GWC. The ASAP layer queues the data to be sent to the GWC
in local buffers until the NS responds.
OK, I think that is it for now.
-- maureen
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.