![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to distribution.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / quipu|
Return to distribution.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / quipu |
1.1 root 1:
2: \chapter {Distributed Operation}
3: \label {dist-op}
4:
5: \section {Overview}
6:
7:
8: Distributed Operation is a major aspect of the QUIPU
9: Directory Service
10: Sadly, the OSI Directory specifications in this area are, in the author's
11: opinion, rather unsatisfactory.
12: Therefore, the QUIPU distributed operations are described in a slightly
13: different manner. The concept of ``Naming Context'' is not used, and the
14: significance of ``Knowledge'' is de-emphasised. The external view of this
15: functionality is fully in line with the standard.
16:
17: Some of the concepts
18: defined in this chapter do {\em not} correspond to the
19: ISO/CCITT terms, and so new terminology is introduced.
20: Standard terminology is used in the standard way.
21:
22:
23: \section {DSA/DUA Interaction Model}
24:
25: There are some interesting choices to be made between DSA Referral and
26: Chaining. A DUA will start by contacting a local DSA, specifying that
27: chaining is preferred (i.e., DSA referrals should not be passed back to the
28: DUA). After that, the first DSA will proceed by use of DSA Referral, except
29: for operations where this is not possible in the QUIPU framework (some cases
30: of search). The advantages of this approach are:
31:
32: \begin {itemize}
33: \item
34: The DUA code can be kept to a minimum, as there is no need to handle
35: referrals.
36: This does mean that the DUA must always interact with the Directory
37: Service through a DSA which supports chaining (which might exclude
38: some implementations).
39: \item
40: Always going thorough a local DSA allows a ``per system'' cache to
41: be maintained in a coherent manner.
42: \item
43: The overhead of maintaining chained connections is not passed
44: on too far.
45: \end {itemize}
46:
47: Note that whilst the DUA procedural does not handle referrals transparently,
48: they are defined in the service interface, so that an application can
49: choose to handle the referrals directly if it wishes to do so.
50:
51: \section {Model of Data Distribution}
52: \label {model-dist}
53:
54: This is a critical section of the design. It is essential to understand it
55: before studying distributed operation.
56:
57: \subsection {Entry Data Blocks}
58:
59: For the root and every non-leaf vertex, there will be an
60: {\em Entry Data Block} (EDB)
61: which contains
62: {\em all}
63: information pertaining
64: to the next level down in the DIT.
65: Figure~\ref{edbf} gives and ASN.1 description of
66: the Entry Data Block format.
67:
68: \tagrind [htbp] {edb}{Entry Data Block Format}{edbf}
69:
70:
71: It should be noted and remembered that
72: the Entry Data Block associated with an entry and described as ``the Entry
73: Data Block of the entry'' contains the entries children (i.e., their
74: attributes and RDNs)
75: and not the attributes of the entry itself.
76: This is {\em not} necessarily intuitive.
77:
78:
79:
80: \subsection {Masters and Slaves}
81:
82: Every Entry Data Block has {\em Master} and {\em Slave} copies.
83: There will typically be only one master (although there may be
84: multiple master copies, where data is maintained ``out of band'').
85: Slave copies are automatically replicated from a Master EDB.
86: This may be direct or indirect. The full propagation path must be acyclic
87: (loop free).
88:
89: A DSA has either all or none of an Entry Data Block
90: as a Master or Slave
91: (viz: Entry Data Blocks are atomic).
92: Any other DIT information it contains is treated as cached
93: data.
94: A DSA does not need to have any Master or Slave data.
95:
96:
97: DSAs are named, and represented in the DIT.
98: One of the reasons for this, is to enable use of the
99: Directory to identify the OSI location of DSAs.
100: This OSI location can then be adjusted transparent to the
101: logical mapping of the DIT onto DSAs.
102: This can be seen as treating a DSA in the same manner as any other
103: Application Entity.
104: This simplifies the implementation, as there does not need to be
105: specific storage of additional configuration information (knowledge).
106:
107: An important piece of information stored in the entry of each DSA is the
108: list of EDBs and how they are replicated. This information is the basis for
109: automatic replication.
110:
111: \subsection {QUIPU Subordinate References}
112:
113: An entry has associated with it, attributes which indicate the
114: DSAs which have Master or Slave Entry Data Blocks for the entry
115: in question.
116: These pointers are known as {\em Quipu Subordinate References} (QSR).
117: For every QSR, the DSA must have a Master or Slave copy of the EDB, as
118: implied by the QSR.
119: The converse it not true: DSAs may have copies of EDBs without there being
120: QSRs.
121: The DSAs with QSRs have the information {\em and} are
122: prepared to answer public queries about the Entry Data Block in
123: question.
124: DSAa with EDBs (typically slave copies) and no QSRs usually have copies for
125: performance or robustness reasons.
126:
127: Quipu Subordinate References are similar to the standardised Non-Specific
128: Subordinate References (NSSR). There are the following differences:
129:
130: \begin {itemize}
131: \item QSRs admit to replication, and therefore there are Master QSRs and
132: Slave QSRs.
133:
134: \item A QSR always points to all of the relevant information, whereas an NSSR
135: may only point to a part of it and must be used in ``and'' conjunction with
136: other NSSRs.
137: \end {itemize}
138:
139:
140: \subsection {Access to the root EDB}
141:
142: There is no requirement for a given DSA to hold a copy of the
143: root Entry Data Block.
144: However, to be able to systematically process all queries, there
145: must be direct or indirect access to the root Entry Data Block.
146: Therefore, every DSA which does not have a copy of the root
147: Entry Data Block must know the name and address of one or more
148: DSA which either has a copy of the root Entry Data Block, or is
149: closer (in terms of these references) to a DSA which has a
150: copy. This approach is similar to, but not the same as, use of superior
151: references defined in the standard.
152:
153: \section {Standard Knowledge References}
154:
155:
156: In addition, to the QUIPU specific QSRs, an entry might also contain
157: standard Knowledge References, as defined in the OSI Directory. This is
158: used to point to data not contained in a QUIPU DSA. There are three types
159: of reference defined in the standard:
160:
161: \begin {description}
162: \item[Subordinate Reference] Pointer to an Entry
163:
164: \item[Cross Reference] From the QUIPU standpoint, the same as a subordinate
165: reference
166:
167: \item[Non Specific Subordinate Reference] Pointer to multiple subordinates
168: which must be queried for the next level down. QSRs are similar to this
169: (see previous section).
170:
171: \end {description}
172:
173: In the first two cases, the entry in the Entry Data
174: Block is considered to be ``Knowledge only'' (although other entry
175: information may be cached).
176: In the third case the entry will also have full information on itself.
177: If any of these are present, there will be no QUIPU master or slave pointers.
178: These three types of pointer are mutually exclusive\footnote{Thought(SEK) ---
179: does the standard let you have a subordinate reference plus a cached NSSR?}.
180:
181: These attributes are not supported in QUIPU 5.0.
182:
183: \section {Navigation}
184:
185: Given this data model, a straightforward navigation algorithm
186: can now be specified.
187: The requirement is to locate the entry associated with a
188: specified Distinguished Name.
189: When the entry is arrived at, the operations will behave
190: as proscribed.
191:
192: The basis of the navigation strategy is that the first DSA (i.e., the one
193: accessed by the DAP) does all of the hard work. Other DSAs, accessed by DSA
194: Referral, either answer the question or return an error. This is important,
195: as it is the basic strategy by which the system ensures completion of
196: queries.
197:
198: First consider the behaviour of a DSA accessed by the Directory
199: System Protocol (DSP):
200:
201: \begin {enumerate}
202: \item
203: Look up the Distinguished Name.
204: \item
205: If the Distinguished Name is found, go to step 6.
206: \item
207: If there is a local copy of
208: the Entry Data Block of the parent,
209: return a nameError.
210: The ``matched'' parameter should be set to the Distinguished Name
211: of the Entry Data Block (i.e., the level above the offered name).
212: This is an authoritative NO.
213: \item
214: Strip the lowest component off the Distinguished Name, and go
215: to step 1.
216: If there are no more components, go to step 5.
217: This process checks for authoritative NO.
218: \item
219: At this point, the name has not been found, and no relevant
220: Entry Data Block has been found.
221: This implies that the DSA does not hold the root Entry Data
222: Block.
223: Therefore the DSA should return a DSA Referral.
224: The DSA Referral should be the list of DSAs (names and
225: addresses) which are known
226: to be closer to the root.
227: \item
228: We now have an entry which matches some or all of the original
229: Distinguished Name.
230: Consider this entry.
231: \item
232: If the entry contains an Alias attribute, dereference, and goto step 1.
233: Note that if a referral is returned, that the appropriate parameters should
234: be set to indicate all dereferences.
235: \item
236: If the entry is the one specified in the query, return the
237: answer to the query, or the appropriate (authoritative) error.
238: \item
239: If the entry is of object class ``QuipuNonLeafObject'', return a Referral.
240: This is simply a redirect to a DSA which can take the query at least one
241: step further. The names for the DSA Referral should be taken from the
242: master and slave Quipu Subordinate References. Where the calling DSA is a
243: non-QUIPU DSA, the Presentation address of the Master DSA must be looked up,
244: and only this one returned.
245: \item
246: If the entry contains a reference, the appropriate referral should be
247: returned.
248: \item
249: The query refers to an entry below the bottom of the DIT.
250: An authoritative nameError can be returned.
251: \end {enumerate}
252:
253: Now consider the slightly more complex case of the initial
254: DSA (doing the DSA Referral).
255: Steps 1-4 are followed as above
256: as above, to determine authoritative NO.
257:
258: \begin {enumerate}
259: \setcounter{enumi}{4}
260: \item
261: At this point, the name has not been found, and no relevant
262: Entry Data Block has been found.
263: This implies that the DSA does not hold the root Entry Data
264: Block.
265: The list of DSAs which are known
266: to be closer to the root, are the starting point for the
267: iterative query.
268: Go to step \ref{step-iter}.
269: \item
270: We now have an entry which matches some or all of the original
271: Distinguished Name.
272: Consider this entry.
273: \item
274: If the entry contains an Alias attribute, apply the relevant
275: dereference to the original query, and go back to the start.
276: \item
277: If the entry is the one specified in the query, return the
278: answer to the query, or the appropriate (authoritative) error.
279: \item
280: If the entry is of object class ``QuipuNonLeafObject'',
281: this gives a list of QSRs to start the iterative query.
282: Go to step \ref{step-iter}.
283: \item
284: If the entry contains a standard knowledge reference, then
285: go to step \ref{step-iter}. Note that for non-specific subordinate
286: references, {\em all} of the references must
287: be followed before giving up.
288: \item
289: The query refers to an entry below the bottom of the DIT.
290: An authoritative nameError can be returned,
291: \item
292: \label{step-iter}
293: Select one of the DSAs from the referral list.
294: The order to try the DSAs is arbitrary.
295: However, it is attempted to select ones with the
296: topologically closest name first (e.g., a UK DSA will prefer to
297: query another UK DSA before asking a French one).
298: Try DSAs in turn until one gives an answer or you get bored.
299: Consider the answer.
300: Authoritative answers (yes or no) should be passed back to the
301: DUA.
302: If a Referral is received, recurse to step, watching
303: carefully for loops.
304: \end {enumerate}
305:
306: It can be seen that this navigation is relying on data being
307: distributed correctly, and DSAs other than the one doing the
308: work behaving in a correct manner.
309: Information provided in the referral should be used to ensure that the
310: iteration is progressing, and thus detect livelock situations.
311:
312:
313:
314: \section {List}
315:
316: The Entry Data Block concept allows the list operation to fall out in a
317: straightforward manner.
318: Navigation to the Entry Data Block belonging to the name provided, will
319: give access to the full result for the list operation.
320:
321: Note that where cross/subordinate references are involved, it will be
322: assumed that these are not alias entries (reasonable in practice).
323: This will allow list to be performed in a single DSA in all cases.
324:
325: \section {Search}
326:
327: This section describes how the OSI Directory search is supported. This is
328: one of the hardest parts of the implementation, and care must be taken.
329: Note that the DAP argument in DSP is always that provided by the
330: DUA\footnote {Whilst this is in principle one of the key aspects of the way
331: the DSP works, the recommendations for distributed operations violate this
332: principle when dealing with aliases during search.}. This means that the
333: work done by a given DSA must be in relation to the target object. With
334: other operations, this is (fairly) straightforward, as the target object
335: always references the base object of the operation. For searching, care
336: must be taken to correctly verify whether the base object has been reached.
337: This is done by use of the operation progress information, setting the name
338: resolution phase to completed.
339:
340: The search operation functions by searching the part of the tree implied
341: by the ``subset'' specification.
342: Rather than returning all of the information, the queried DSA will apply
343: the associated filter to the entries in question, and return the
344: filtered result, along with appropriate continuation pointers.
345: This should minimise network traffic.
346:
347:
348: The case of ``subset = baseObject'' is handled by navigating to the Entry
349: Data Block of the object's parent, and applying the given filter.
350: If the entry is a cross reference or subordinate reference, the reference
351: should be followed (using the same query).
352:
353: The case of ``subset = oneLevel'' is handled by navigating to the object's
354: own Entry Data Block.
355: There the filter is applied to each of its children.
356: If any of the children are alias entries, the alias should be
357: de-referenced, and a baseObject search applied to the new entry.
358: For each child which is a cross references or subordinate references,
359: the references should be followed, setting the target object to be the child.
360:
361: The case of ``subset = wholeSubtree'' is handled by navigating to the
362: object's own Entry Data Block.
363: There, the filter is applied to the object and to each of its
364: children\footnote{QUIPU 5.0 gets this wrong, and does not apply the filter
365: to the base object.}.
366: If any of the children are alias entries, the alias should be
367: de-referenced, and a wholeSubtree search applied to the new entry.
368: For each child which has QUIPU children (determined
369: by the prescence of a masterDSA attribute), the search should be applied to
370: the master or one of the slave DSAs, with target object set to the child.
371: For each child which is a cross reference or subordinate reference,
372: the references should be followed, setting the target object to the child.
373: For each child which has non-specific subordinate references, the search
374: should be applied to {\em all} of the referenced DSAs, with the target
375: object set to the child.
376:
377: There are three procedures for operating:
378:
379: \begin {enumerate}
380: \item Everything handled by the first DSA, with other DSAs returning a
381: mixture of results and partial outcome qualifiers. This is not currently
382: supported due to some awkward implications of holding state, but will be the
383: default in QUIPU 6.0.
384:
385: \item Proceed by referral until a DSA is reached which has a copy of the
386: base object. Then this DSA proceeds by referral, and returns the full
387: result to the first DSA. This is how QUIPU 5.0 works. It has the advantage
388: of often accumulating search results in a local environment, and so will be
389: selectable in QUIPU 6.0 (possibly in a complex manner).
390:
391: \item Proceed by referral until a DSA is reached which has a copy of the
392: base object. Then proceed entirely by chaining. This is not done.
393:
394: \end {enumerate}
395:
396:
397: There is potential for looping in this procedure.
398: This will be detected and broken by noting loops in the DSA trace
399: information.
400: This takes account of the fact that some distribution will allow
401: for a query to re-enter the same DSA a number of times.
402:
403:
404: The Search and list operations make use of the ``partial results''
405: functionality to return information if a time or size limit is reached.
406: Thus, setting a low size limit will allow a user to easily examine
407: sample information (either by list or search).
408:
409: \section {Unavailable DSAs}
410:
411: In the case where a DSA is unavailable, and chaining is preferred, a reference
412: will be returned by a QUIPU DSA.
413: A QUIPU DUA, which knows it is talking to a QUIPU DSA
414: can rely on this behaviour, and simply use the referral as a diagnostic to
415: the user. It is hoped that the next version of the standard will add an
416: obvious extra parameter.
417:
418:
419:
420: \section {Presentation Addresses}
421:
422: In terms of the directory, presentation addresses are handled according to
423: the standard. Presentation addresses are stored in text form according to
424: \cite {PSAP.String}. The network encoding follows \cite {NSAP.Approach}.
425:
426: \section {Operating When DSAs are not fully interconnected}
427: \label {tcp-only}
428:
429: Whilst global interconnection of all application entities is an OSI ideal,
430: it will not be achievable in the short or medium term. Application relaying
431: by DSAs will be needed to achieve full directory connectivity.
432:
433:
434: In general, it is not desirable for DSAs to proceed by chaining - it wastes
435: unnecessary application level resources. Later, there may be policy reasons
436: to prefer chaining, but these are ignored for now. The internal structure
437: of network addresses allows a DSA to determine if two DSAs can communicate
438: directly. For QUIPU 5.0, referrals will be used if the calling and
439: referenced DSA can communicate directly and chaining otherwise. For QUIPU
440: 6.0, authorisation will be required for chaining to take place.
441:
442:
443: \section {The External view of QUIPU}
444:
445: To a non-QUIPU system, QUIPU will appear to work exactly according to the
446: standard. This is not quite true for QUIPU 5.0, but is sufficiently close to
447: allow a high level of interworking with a non-QUIPU system. This is an
448: optimistic statement, not written in the light of experience with
449: interoperability testing.
450:
451: When a QUIPU DSA interacts with another DSA, it will look up its object
452: classes (and probably other information). This will allow it to determine if
453: the other DSA is a QUIPU DSA. When interacting with another QUIPU DSA, the
454: following deviations from the standard are possible. These are primarily
455: concerned with the introduction of replication:
456:
457: \begin {itemize}
458: \item Presentation Address might be omitted from Access Point (always
459: present in QUIPU 5.0, for consideration in QUIPU 6.0).
460: \item Cross References and Subordinate References have multiple values
461: (although QUIPU will probably never send these to itself).
462: \item Multiple values of Non Specific Subordinate Reference are assumed to
463: have OR conjunction (i.e., they are really QSRs).
464: \item Use of QUIPU Access control as describe in Section~\ref{dsp-acl}
465: \end {itemize}
466:
467: When a QUIPU DSA returns references which are derived from reference
468: attributes, it will return them as specified. If it returns information
469: derived from QUIPU internal pointers, it will return a non-specific
470: subordinate reference. If the DSA being communicated with is not a QUIPU
471: DSA, it will return only a reference to the master DSA (as replication is
472: not admitted within the protocol).
473:
474: \section {Use of ACLs in DSP}
475: \label{dsp-acl}
476:
477: Within the DSP, between a pair of QUIPU DSAs, the ACL
478: attribute becomes special. It is used as a roadmap of the entry for
479: a DSA which is caching information. For this reason, the ACL is
480: always asked for in read operations invoked by DSP --- irrespective
481: of whether the corresponding DAP operation asked for it. The ACL
482: will always be returned to the DSA, even if the DUA in question does
483: not have rights to it. This will allow the DSA to perform caching
484: ``correctly''. When an ACL is passed in the DSP, it will be encoded
485: so that ALL of the attributes of the entry are explicitly referred
486: to. Thus, the caching DSA will be able to determine whether or not
487: it has all the attributes of a given entry. This should be a useful
488: performance gain.
489:
490: This will be added in QUIPU 6.0.
491:
492: \section {Access Control and Authentication}
493:
494: All operations must take account of access control prior to being performed.
495: Authentication must be done at BIND time, as this is the only point at which
496: the DSA can return an error to the DUA which indicates authentication
497: failure.
498:
499: If there is public right on the information, then the effort of doing the
500: authentication was wasted.
501: Therefore, if a user is accessing information {\em known} to be publicly
502: readable, it will be optimal {\em not} to supply credentials.
503:
504: For policy reasons, QUIPU 6.0 may make specification of DUA and the
505: associated simple authentication mandatory.
506:
507: \section {Cached Data}
508: \label {cache-all}
509:
510: Cached data is not mentioned in the basic algorithm.
511: However, the algorithm can utilise cached
512: data in some circumstances.
513: This is because of the manner in which identification of copy data has been
514: introduced in the final stage of the OSI Directory specification.
515: Cached data may be used whenever this is not prohibited by the service
516: controls.
517: The standard does not clearly define what ``copy'' data is. In general,
518: QUIPU treats master and slave data as authoritative.
519: Both slave and cached data are returned to the user as
520: ``copy'' data. For this reason, the distinction between slave and copy data
521: can only be internal to QUIPU.
522:
523: There is no time to live or age information in the OSI Directory Protocols.
524: Care must be taken when caching, that spurious information is not passed
525: around indefinitely between DSAs
526:
527: When QUIPU holds cached data, it will note:
528:
529: \begin {itemize}
530: \item How long it has had it
531: \item If it came from a master, slave, or cache.
532: \item If it is complete (e.g., are all values of an attribute present)
533: \end {itemize}
534:
535: This section is open ended.
536: The exact approaches to caching, and determining suitable timeout values
537: will be the subject of experiment.
538:
539: QUIPU 5.0 supports the caching techniques described in section
540: \ref{cache-all}, except:
541:
542: \begin {itemize}
543: \item Holding age information
544: \item Storage on disk
545: \item Timeouts
546: \item Negative caching
547: \end {itemize}
548:
549:
550: \subsection {Caching Configuration Data}
551:
552:
553: When the DSA is using cached data (e.g., the Presentation Address of another
554: DSA), it should be aware of this fact, and should update the information
555: (from non-cache information) if it fails to establish an OSI connection,
556: or some inconsistency appears to occur in the data. If there is some doubt
557: (e.g., if the error might be due to the DSA being unavailable), the age of
558: the cache should be take into account when determining whether or not to do
559: a refresh.
560:
561: The important thing about managing cached data is to handle timeouts
562: sensibly.
563: Data cached from a cache may have an indeterminate age.
564: It is important that this data is given a relatively short timeout, to
565: prevent it being circulated indefinitely amongst a set of DSAs.
566: However, {\em if} the data can be verified by usage (e.g., correctly
567: connecting to a DSA verifies a presentation address), it should then be
568: treated as if cached from a master/slave.
569: Non-verified data should be treated in the same manner as user data, which
570: is described in the next section.
571: Data cached from master/slave information should be given a longer timeout.
572: Data is discarded, rather than refreshed automatically. A timeout of some
573: number of days seems appropriate for most data.
574:
575: A special case is made for comparing passwords, because it is a user
576: expectation to use the new password immediately. For this reason, if a
577: password compare fails, a check should be made against the master copy.
578: Note that old passwords will sometimes be valid for a
579: short while beyond their change.
580:
581: \subsection {Caching User Data}
582:
583: User data is cached in a manner similar to configuration data. Data cached
584: from a cache will only be held for a short period of time (perhaps a few
585: minutes). This time should be short enough to ensure that spurious cached
586: information will die out, but long enough to give the necessary performance
587: improvements for repeated queries.
588:
589: Other data may be cached for longer. If ever a query is made asking for
590: authoritative data, any cached values should be flushed immediately ---
591: irrespective of whether the query succeeds. A query for authoritative data
592: is a strong hint about the inaccuracy of cached data, or that a recent
593: change might have occurred.
594:
595: \subsection {Negative Data}
596:
597: Usage of directories has shown that incorrect queries are often repeated,
598: particularly when the user is a mail system. For this reason, negative
599: answers will be cached for a short period of time (QUIPU 6.0).
600:
601: \subsection {Writing Caches to disk}
602: \label {disk-cache}
603:
604: This is beyond the scope of QUIPU 5.0, but essential for QUIPU 6.0 for
605: improved performance.
606:
607: The astute will notice that without any cached information, DSA startup for
608: DSAs which do not have copies of a few relevant EDBs, will be an expensive
609: operation.
610: Data cached from a cache will never be saved on disk.
611:
612: Disk caching is important to ensure that this overhead is only be incurred
613: in practice, on the occasion of the initial startup. This means that QUIPU
614: 5.0 DSAs (without disk caching) should always be given copies of at least
615: their parent EDB.
616:
617: \section {Configuration and Slave Update}
618:
619: A given DSA will have copies of zero or more Entry Data Blocks.
620: A DSA may either be a master for a given Entry Data Block, or a
621: slave.
622: If there are multiple master copies, it is assumed that these
623: are kept coherent by some out of band mechanism.
624: For example, one of them is the ``real'' master, and the others
625: are updated by file transfer when modifications occur.
626: This discussion will proceed for the single master case.
627:
628: There are three distinct types of DSA:
629:
630: \begin {enumerate}
631: \item
632: A DSA with a master copy of the root Entry Data Block.
633: \item
634: A DSA with a slave copy of the root Entry Data Block.
635: \item
636: A DSA with no copy of the root Entry Data Block.
637: \end {enumerate}
638:
639: As noted in Section~\ref{model-dist}, DSAs of type 2 and 3 will have pointer(s) to
640: a DSA which is ``closer'' to the master copy of the root Entry
641: Data Block.
642: Specifying this hierarchical distribution, as opposed to requiring
643: direct access to the master (as in earlier versions of the OSI Directory)
644: means that there can be many copies of information which needs to be highly
645: replicated, without excessive
646: redundant copying across the Wide Area Network.
647: This will be particularly important for the root Entry Data Block.
648:
649: DSAs of type 2 will only need the pointer information for initial
650: startup or recovery after catastrophic corruption.
651: When the slave copy of the root Entry Data Block has been
652: obtained for the first time, this will supercede the pointers.
653: DSAs of type 3 will usually use cached information in preference to
654: these pointers, and will only need the pointers if cached information is
655: (or appears to be) invalid.
656:
657: The only information which a DSA has to obtain locally at initial boot time,
658: other than the DSA pointers, is its own name. All other information may be
659: obtained from the Directory.
660: Beyond this, the Directory Service manages its own
661: configuration.
662: There is little point in having a Directory Service providing
663: general high speed access to global information, and then
664: requiring an additional system (knowledge) to deal with its own
665: configuration.
666:
667: Associated with the DSA's entry in the DIT is a specification of
668: the entries for which the DSA is a master, and for which it is
669: a slave.
670: A DSA will be able to derive the location of an Entry Data
671: Block for which it is master from this information.
672: Thus at initial boot, a DSA will utilise its initial DSA pointers
673: to read its own entry.
674: The location of master Entry Data Blocks will be derivable from
675: their name, and so their existence can then be verified by the
676: DSA in question.
677: A DSA which is a master for the root Entry Data Block will have
678: no pointers.
679: However, it can go straight to the master root Entry Data
680: Block, read the information about itself, and proceed as for
681: other DSAs.
682:
683:
684: It is believed that for early pilots, a high level of copying configuration
685: data will be desirable to achieve robustness. The root and national EDBs
686: will be very highly replicated, even though QUIPU can operate with a rather
687: low level of replication.
688:
689: \section {DSA Naming}
690: \label {dsa-naming}
691:
692: \subsection {Choice of Names to prevent loops}
693:
694: Care must be taken to prevent the situation where the location
695: of a DSA is only known through itself (and other more complex
696: variants).
697: A simple rule for naming DSAs will ensure that this cannot
698: happen.
699: The master DSA for a given entry (i.e., the DSA controlling the Entry Data Block of
700: containing
701: the entry's children) should have its
702: name in the Entry Data Block of the entry's parent or at a
703: level higher in the DIT.
704: For example, the master DSA of
705: \begin{quote}\small\begin{verbatim}
706: Country=UK, Org=University College London, OU=Computer Science
707: \end{verbatim}\end{quote}
708: which contains information on entries below Computer Science, may be labelled
709: \begin{quote}\small\begin{verbatim}
710: Country=UK, Org=University College London, DSA=Three Toed Sloth
711: \end{verbatim}\end{quote}
712: or
713: \begin{quote}\small\begin{verbatim}
714: Country=France, DSA=Capybara
715: \end{verbatim}\end{quote}
716: It may not be labelled
717: \begin{quote}\small\begin{verbatim}
718: Country=UK, Org=University College London, OU=Computer Science,
719: DSA=Alpaca
720: \end{verbatim}\end{quote}
721: or
722: \begin{quote}\small\begin{verbatim}
723: Country=France, Org=Inria, DSA=Llama
724: \end{verbatim}\end{quote}
725:
726:
727: A little more flexibility could be allowed;
728: However, this rule is simple, it prevents deadlock, and allows
729: for reasonable labelling practices.
730: The restriction may be relaxed somewhat, when the concept of Directory
731: Management Domains is introduced more formally.
732:
733: \section {Local DSA Information}
734:
735:
736: The basic entry for the DSA contains information which must be widely known.
737: Essentially this is the OSI location of the DSA. There is other information
738: which it is useful to store in the Directory, but which is primarily needed
739: by the DSA itself. Because of the naming rules in the previous section, the
740: DSA's entry will usually be mastered in a different DSA. Therefore, we have
741: a second entry for each DSA, which is the child of the prime DSA Entry.
742: This entry will always have common name ``Info'', and be mastered in the DSA
743: itself. There will usually not be slave copies. The DSA Address is also
744: stored in this entry. This duplication (and therefore extra management) is
745: seen as worthwhile, as it allows a DSA to start without access to any other
746: DSA. This information may be absent (usually only when a DSA is being
747: created).
748:
749: Initially, the following information will be stored in this entry:
750:
751: \begin {itemize}
752: \item The EDB management information
753: \item DSA Control (see Section~\ref{dsa-control})
754: \item Software Version --- this attribute is automatically maintained
755: by the DSA.
756: \end {itemize}
757:
758: For QUIPU 5.0, these entries are supported, but are in the main DSA entry.
759:
760: The following items will be added for QUIPU 6.0, to allow for more
761: sophisticated remote
762: management:
763:
764: \begin {itemize}
765: \item Authorisation policy
766: \item Tailoring
767: \item The schema files (OID, Attribute, Object Class)
768: \end {itemize}
769:
770: Replication will also allow common management of multiple DSAs (e.g., to share
771: a common schema).
772:
773:
774: \section {DSA Naming Architecture }
775:
776: The following Naming Architecture components are needed in order to support
777: the QUIPU Mechanism for distributed operations.
778: These are defined here, as a convenient location.
779: Numbers are assigned in the QUIPU Naming Architecture contained in Volume~5
780: of the User's
781: Manual \cite{QUIPU.Manual}.
782:
783: \tagrindfile {na}{Naming Architecture}{na}
784:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.