Revised proposol CLNS domain object:

Based on the outcome of some discussion during the presentation of the
dom-prefix at the last RIPE database workgroup meeting I have added/changed
the following.

	1: Prefixes or NSAPs are to be formatted with dots.
	   The first dot defines the AFI and comes after the
	   first two digits.
	   Every next four digits should be seperated by dots.
	2: The cost associated with default routing should be interpreted
	   such that the prefered path has the lowest cost.


 - Henk Steenman

----------------------------- Cut here -------------------------------------






















                      CLNS routing-domain object for the
                                RIPE database


				Version 1.3

                                  Feb 1994
























Henk Steenman
Henk_Steenman at sara.nl
+31 20 5928038



CLNS routing-domain object                                            Page 2



Introduction.
____________

In the RARE lower layer technology work group for CLNS it was recognised that
in order to coordinate routing between CLNS routing domains a central registry
for such domains was necessary.
At a meeting of the work group at the 27 IETF in Amsterdam it was decided to
write a registry specification. At this meeting the RIPE NCC offered to extend
their database for IP domains/networks with CLNS related objects if a sound
proposal came forward.

Below a description of a database object for CLNS routing domains is defined.
The object can be used to describe some general information of a CLNS routing
domain such as NSAP prefix, name, description and responsible persons. It can
also be used to describe routing policies in a manner comparable to that for
IP domains ( AS's ) as defined in the paper RIPE 81 [1].

The attributes describing routing policy are intended to be set-up such that
routing tables for static inter-domain routing can be derived from them or
excisting routing can be checked against the described policy.

It is desired that tools are made to serve these tasks.

It is understood that the object as described below is subject to change when
CLNS routing developes. An example of this could be the future availability of
IDRP for dynamic inter-domain routing.

In an appendix, some generally used combinations of the Authority and Format
Identifier (AFI) and the Initial Domain Identifier (IDI) are shown.

The RIPE database expects NSAPs or prefixes to be formatted with dots,
seperating the first two and then every next four digits.


CLNS routing-domain object                                            Page 3



Object Description
_________________

dom-prefix:

	Defines an unique routing domain, characterised by a
	NSAP prefix , within a certain prefix hierarchy.

	Example:

	dom-prefix: 39.528f.1100

dom-name:

	String representing the routing domain.

	Format: Text string.

	Example:

	dom-name: SURFnet-CLNS

descr:

	Description of the organisation and place of its location
	Format is equal to the descr attribute as defined for IP
	autonomous systems in [1].

bis:

	Format : < bis NET > < dom-prefix >

	NET of boundary intermediate system to between two
	domains

	Example: SURFnet BIS for EuropaNet

	bis: 39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 39.528f.1103


CLNS routing-domain object                                            Page 4



dom-in:



	Description of accepted routing domain prefixes, from
	other domain BIS. Analogue to "as-in" in [1].

	Format:< dom-prefix > < cost> <routing policy expression >

	For every BIS you peer with, there should be such an entry

	<dom-prefix> is the routing domain prefix where the BIS
	you peer with belongs to.

	<cost> is a relative cost to discriminate between different
	routes to the same domain. The lowest cost gives the most
	preferred route.

	<routing policy expression > can be expressed in the
	following way's

	1: list of "dom-prefixes"

	Example:

	dom-in: 39.528f.1103 100 39.124F 47.0005

	2: KEYWORD

	Only one keyword for the moment
	ANY - accept everything you get announced.

	3: A logical expression of 1 and/or 2.

	The following operators should be defined
	AND
	OR
	NOT
	Parenthesis are used to group rules.

	Example:

	dom-in: 39.528f.1103 ANY AND NOT 39.756f

	Accept all announcements from EMPB BIS except for the
	Switzerland routing domain.


CLNS routing-domain object                                            Page 5



dom-out:

	Routing domain prefixes announced to other BIS'.
	Analogue to the "as-out' tag in [1].


	Format : < dom-prefix > <routing policy expression >

	<dom-prefix> is the routing domain prefix where the BIS
	you peer with belongs to.

	<routing policy expression > As defined with the dom-in
	tag.



	Example:

	dom-out: 39.528f.1103 39.528f.1100 AND NOT 39.528f.1100.0009.10

	Advertise to Europanet the SURFnet-CLNS routing
	domain but not the PTT-Research routing domain.

default:

	Indication how default routing is done

	default:  < dom-prefix> <cost>

	<dom-prefix> again is the prefix of the domain where the
	BIS peer is in.

	<cost> indicates which default path is preferred.
	The lower cost gives the preffered path

	Example:

	default: 39.528f.1103 10

	Default everything is routed to 39.528f.1103


CLNS routing-domain object                                            Page 6



admin-c:

	Administrative contact.
	Format equal to  admin-c   in [1].

tech-c:

	Technical contact
	Format equal to  tech-c   in [1].

guardian:

	e-mail and/or postal address of domain guardian.
	Analogue to AS guardian in [1].

source:

	Source of the information.
	Equal to source field in [1].

remark:

	remarks or comments
	Equal to  remark  field in [1]

changed:

	Who and when of last change.
	Equal to change field in [1].


CLNS routing-domain object                                            Page 7



Example:
_________

dom-prefix:	39.528f.1100
descr:		SURFnet-CLNS domain.
bis:		39.528f.1100.1000.2000.0000.0001.0000.0c04.29b4.00 39.528f.1103
dom-in:		39.528f.1103 100 ANY AND NOT 39.528f.1100.0009.10
dom-in:		39.528f.1100.0009.10 100 39.528f.1100.0009.10
dom-out:	39.528f.1103 39.528f.1100 AND NOT 39.528f.1100.0009.10
dom-out:	39.528f.1100.0009.10 39.528f.1100
default:	39.528f.1103 10
admin-c:	Victor Reijs
tech-c:		Henk Steenman
guardian:	domain-guardian at surfnet.nl
source:		RIPE
changed:	henk at sara.nl 930716

SURFnet accepts from EMPB ( 39528f1103 ) all prefixes but one,
39.528f.1100.0009.10, which is PTT-research that is connected to both EMPB
and SURFnet. From PTT-research SURFnet only accepts the PTT-research prefix.

SURFnet announces to EMPB, 39.528f.1100 but not 39.528f.1100.0009.10.
To PTT-research only 39.528f.1100 is announced.

Translated to static routing; on the SURFnet BIS connected to PTT-
research, there is a static route to 39.528f.1100.0009.10. And on the SURFnet
BIS connected to EMPB there is a static route to all other
know prefixes. On both the PTT-reserach and EMPB BIS's connected
to SURFnet there is a static route to 39.528f.1100.


CLNS routing-domain object                                            Page 8


Appendix A.
___________

Definition of NSAP structure is defined in OSI 8348 Ad2 [2].

In general:

NSAP's are always an integer number of octets where the AFI is always one
octet and the IDI is always an integer number of octets.

NSAP's are hierarchical structured and once the AFI is decided upon,
structuring of the rest of the NSAP is up to authorities down the tree.

Two common AFI are 47 and 39 and can be described by some general rules.

AFI: 39

Describes that the following two octets are the ISO DCC country codes. Since
these codes are always described by three digits, padding with an "f" is
necessary to complete the 2 octets. Further structure is done by the authority
for each country and there is no general rule.

AFI: 47

IDI: 4 defines OSINET.



Followed by a two byte organisation identifier.

IDI: 5 defines US-GOSIP

Version 1 defines a two byte organisation identifier.

Version 2 defines a one byte data format identifier,
	a two byte zero field
	a three byte administrative authority
	a two byte routing domain id.


CLNS routing-domain object                                            Page 9



References
__________

[1] :
RIPE-81, Representation of IP routing Policies in the RIPE database,
Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg and
Marten Terpstra, Feb. 1993

[2] :
OSI 8348 Ad2
Network Services Definition, Addendum 2, covering Network Layer Addressing.
--------