5.3.  Administration at the Provider Routing Domain

   Two kinds of provider routing domains are considered, direct
   providers and indirect providers.  Most of the subscribers of a
   direct provider are domains that act solely as service subscribers
   (i.e., they carry no transit traffic).  Most of the "subscribers" of

   an indirect provider are, themselves, service providers.  In present
   terminology a backbone is an indirect provider, while a regional is a
   direct provider.  Each case is discussed separately below.

5.3.1.  Direct Service Providers

   It is interesting to consider whether direct service providers'
   routing domains should be the common authority for assigning NSAPs
   from a unique prefix to the subscriber routing domains that they
   serve.  In the long term the number of routing domains in the
   Internet will grow to the point that it will be infeasible to route
   on the basis of a flat field of routing domains.  It will therefore
   be essential to provide a greater degree of information abstraction.

   Direct providers may assign prefixes to subscriber domains, based on
   a single (shorter length) address prefix assigned to the provider.
   For example, given the GOSIP Version 2 address structure, an AA value
   may be assigned to each direct provider, and routing domain values
   may be assigned by the provider to each attached subscriber routing
   domain.  A similar hierarchical address assignment based on a prefix
   assigned to each provider may be used for other NSAP formats.  This
   results in direct providers advertising to other providers (both
   direct and indirect) a small fraction of the number of address
   prefixes that would be necessary if they enumerated the individual
   prefixes of the subscriber routing domains.  This represents a
   significant savings given the expected scale of global
   internetworking.

   Are subscriber routing domains willing to accept prefixes derived
   from the direct providers? In the supplier/consumer model, the direct
   provider is offering connectivity as the service, priced according to
   its costs of operation.  This includes the "price" of obtaining
   service from one or more indirect providers and exchanging routing
   information with other direct providers.  In general, providers will
   want to handle as few address prefixes as possible to keep costs low.
   In the Internet environment, subscriber routing domains must be
   sensitive to the resource constraints of the providers (both direct
   and indirect).  The efficiencies gained in routing clearly warrant
   the adoption of NSAP administration by the direct providers.

   The mechanics of this scenario are straightforward.  Each direct
   provider is assigned a unique prefix, from which it allocates
   slightly longer routing domain prefixes for its attached subscriber
   routing domains.  For GOSIP NSAPs, this means that a direct provider
   would be assigned an AA identifier.  Attached subscriber routing
   domains would be assigned RD identifiers under the direct provider's
   unique prefix.  For example, assume that NIST is a subscriber routing
   domain whose sole inter-domain link is via SURANet.  If SURANet is

   assigned an AA identifier kkk, NIST could be assigned an RD of jjj,
   resulting in a unique prefix for SURANet of:

   AFI=47, IDI=0005, DFI=80h, AA=kkk

   and a unique prefix for NIST of

   AFI=47, IDI=0005, DFI=80h, AA=kkk, (Rsvd=0), RD=jjj.

   A similar scheme can be established using NSAPs allocated under
   DCC=840.  In this case, a direct provider applies for an ORG
   identifier from ANSI, which serves the same purpose as the AA
   identifier in GOSIP.

5.3.2.  Indirect Providers

   There does not appear to be a strong case for direct service
   providers to take their address spaces from the NSAP space of an
   indirect provider (e.g. backbone in today's terms).  The benefit in
   routing data abstraction is relatively small.  The number of direct
   providers today is in the tens and an order of magnitude increase
   would not cause an undue burden on the indirect providers.  Also, it
   may be expected that as time goes by there will be increased direct
   inter-connection of the direct providers, subscriber routing domains
   directly attached to the "indirect" providers, and international
   links directly attached to the providers.  Under these circumstances,
   the distinction between direct and indirect providers would become
   blurred.

   An additional factor that discourages allocation of NSAPs from an
   indirect provider's prefix is that the indirect providers and their
   attached direct providers are perceived as being independent.  Direct
   providers may take their indirect provider service from one or more
   providers, or may switch indirect providers should a more cost-
   effective service be available elsewhere (essentially, indirect
   providers can be thought of the same way as long-distance telephone
   carriers).  Having NSAPs derived from the indirect providers is
   inconsistent with the nature of the relationship.

5.4.  Multi-homed Routing Domains

   The discussions in Section 5.3 suggest methods for allocating NSAP
   addresses based on service provider connectivity.  This allows a
   great deal of information reduction to be achieved for those routing
   domains which are attached to a single provider.  In particular, such
   routing domains may select their NSAP addresses from a space
   allocated to them by their direct service provider.  This allows the
   provider, when announcing the addresses that it can reach to other

   providers, to use a single address prefix to describe a large number
   of NSAP addresses corresponding to multiple routing domains.

   However, there are additional considerations for routing domains
   which are attached to multiple providers.  Such "multi-homed" routing
   domains may, for example, consist of single-site campuses and
   companies which are attached to multiple providers, large
   organizations which are attached to different providers at different
   locations in the same country, or multi-national organizations which
   are attached to providers in a variety of countries worldwide.  There
   are a number of possible ways to deal with these multi-homed routing
   domains.

   One possible solution is to assign addresses to each multi-homed
   organization independently from the providers to which it is
   attached.  This allows each multi-homed organization to base its NSAP
   assignments on a single prefix, and to thereby summarize the set of
   all NSAPs reachable within that organization via a single prefix.
   The disadvantage of this approach is that since the NSAP address for
   that organization has no relationship to the addresses of any
   particular provider, the providers to which this organization is
   attached will need to advertise the prefix for this organization to
   other providers.  Other providers (potentially worldwide) will need
   to maintain an explicit entry for that organization in their routing
   tables.  If other providers do not maintain a separate route for this
   organization, then packets destined to this organization will be
   lost.

   For example, suppose that a very large U.S.-wide company "Mega Big
   International Incorporated" (MBII) has a fully interconnected
   internal network and is assigned a single AA value under the U.S.
   GOSIP Version 2 address space.  It is likely that outside of the
   U.S., a single entry may be maintained in routing tables for all U.S.
   GOSIP addresses.  However, within the U.S., every "default-less"
   provider will need to maintain a separate address entry for MBII.  If
   MBII is in fact an international corporation, then it may be
   necessary for every "default-less" provider worldwide to maintain a
   separate entry for MBII (including providers to which MBII is not
   attached).  Clearly this may be acceptable if there are a small
   number of such multihomed routing domains, but would place an
   unacceptable load on routers within providers if all organizations
   were to choose such address assignments.  This solution may not scale
   to internets where there are many hundreds of thousands of multi-
   homed organizations.

   A second possible approach would be for multi-homed organizations to
   be assigned a separate NSAP space for each connection to a provider,
   and to assign a single address prefix to each area within its routing

   domain(s) based on the closest interconnection point.  For example,
   if MBII had connections to two providers in the U.S. (one east coast,
   and one west coast), as well as three connections to national
   providers in Europe, and one in the far east, then MBII may make use
   of six different address prefixes.  Each area within MBII would be
   assigned a single address prefix based on the nearest connection.

   For purposes of external routing of traffic from outside MBII to a
   destination inside of MBII, this approach works similarly to treating
   MBII as six separate organizations.  For purposes of internal
   routing, or for routing traffic from inside of MBII to a destination
   outside of MBII, this approach works the same as the first solution.

   If we assume that incoming traffic (coming from outside of MBII, with
   a destination within MBII) is always to enter via the nearest point
   to the destination, then each provider which has a connection to MBII
   needs to announce to other providers the ability to reach only those
   parts of MBII whose address is taken from its own address space.
   This implies that no additional routing information needs to be
   exchanged between providers, resulting in a smaller load on the
   inter-domain routing tables maintained by providers when compared to
   the first solution.  This solution therefore scales better to
   extremely large internets containing very large numbers of multi-
   homed organizations.

   One problem with the second solution is that backup routes to multi-
   homed organizations are not automatically maintained.  With the first
   solution, each provider, in announcing the ability to reach MBII,
   specifies that it is able to reach all of the NSAPs within MBII.
   With the second solution, each provider announces that it can reach
   all of the NSAPs based on its own address prefix, which only includes
   some of the NSAPs within MBII.  If the connection between MBII and
   one particular provider were severed, then the NSAPs within MBII with
   addresses based on that provider would become unreachable via inter-
   domain routing.  The impact of this problem can be reduced somewhat
   by maintenance of additional information within routing tables, but
   this reduces the scaling advantage of the second approach.

   The second solution also requires that when external connectivity
   changes, internal addresses also change.

   Also note that this and the previous approach will tend to cause
   packets to take different routes.  With the first approach, packets
   from outside of MBII destined for within MBII will tend to enter via
   the point which is closest to the source (which will therefore tend
   to maximize the load on the networks internal to MBII).  With the
   second solution, packets from outside destined for within MBII will
   tend to enter via the point which is closest to the destination

   (which will tend to minimize the load on the networks within MBII,
   and maximize the load on the providers).

   These solutions also have different effects on policies.  For
   example, suppose that country "X" has a law that traffic from a
   source within country X to a destination within country X must at all
   times stay entirely within the country.  With the first solution, it
   is not possible to determine from the destination address whether or
   not the destination is within the country.  With the second solution,
   a separate address may be assigned to those NSAPs which are within
   country X, thereby allowing routing policies to be followed.
   Similarly, suppose that "Little Small Company" (LSC) has a policy
   that its packets may never be sent to a destination that is within
   MBII.  With either solution, the routers within LSC may be configured
   to discard any traffic that has a destination within MBII's address
   space.  However, with the first solution this requires one entry;
   with the second it requires many entries and may be impossible as a
   practical matter.

   There are other possible solutions as well.  A third approach is to
   assign each multi-homed organization a single address prefix, based
   on one of its connections to a provider.  Other providers to which
   the multi-homed organization are attached maintain a routing table
   entry for the organization, but are extremely selective in terms of
   which indirect providers are told of this route.  This approach will
   produce a single "default" routing entry which all providers will
   know how to reach the organization (since presumably all providers
   will maintain routes to each other), while providing more direct
   routing in those cases where providers agree to maintain additional
   routing information.

   There is at least one situation in which this third approach is
   particularly appropriate.  Suppose that a special interest group of
   organizations have deployed their own backbone.  For example, lets
   suppose that the U.S. National Widget Manufacturers and Researchers
   have set up a U.S.-wide backbone, which is used by corporations who
   manufacture widgets, and certain universities which are known for
   their widget research efforts.  We can expect that the various
   organizations which are in the widget group will run their internal
   networks as separate routing domains, and most of them will also be
   attached to other providers (since most of the organizations involved
   in widget manufacture and research will also be involved in other
   activities).  We can therefore expect that many or most of the
   organizations in the widget group are dual-homed, with one attachment
   for widget-associated communications and the other attachment for
   other types of communications.  Let's also assume that the total
   number of organizations involved in the widget group is small enough
   that it is reasonable to maintain a routing table containing one

   entry per organization, but that they are distributed throughout a
   larger internet with many millions of (mostly not widget-associated)
   routing domains.

   With the third approach, each multi-homed organization in the widget
   group would make use of an address assignment based on its other
   attachment(s) to providers (the attachments not associated with the
   widget group).  The widget backbone would need to maintain routes to
   the routing domains associated with the various member organizations.
   Similarly, all members of the widget group would need to maintain a
   table of routes to the other members via the widget backbone.
   However, since the widget backbone does not inform other general
   world-wide providers of what addresses it can reach (since the
   backbone is not intended for use by other outside organizations), the
   relatively large set of routing prefixes needs to be maintained only
   in a limited number of places.  The addresses assigned to the various
   organizations which are members of the widget group would provide a
   "default route" via each members other attachments to providers,
   while allowing communications within the widget group to use the
   preferred path.

   A fourth solution involves assignment of a particular address prefix
   for routing domains which are attached to two or more specific
   cooperative public service providers.  For example, suppose that
   there are two providers "SouthNorthNet" and "NorthSouthNet" which
   have a very large number of customers in common (i.e., there are a
   large number of routing domains which are attached to both).  Rather
   than getting two address prefixes (such as two AA values assigned
   under the GOSIP address space) these organizations could obtain three
   prefixes.  Those routing domains which are attached to NorthSouthNet
   but not attached to SouthNorthNet obtain an address assignment based
   on one of the prefixes.  Those routing domains which are attached to
   SouthNorthNet but not to NorthSouthNet would obtain an address based
   on the second prefix.  Finally, those routing domains which are
   multi-homed to both of these networks would obtain an address based
   on the third prefix.  Each of these two providers would then
   advertise two prefixes to other providers, one prefix for subscriber
   routing domains attached to it only, and one prefix for subscriber
   routing domains attached to both.

   This fourth solution could become important when use of public data
   networks becomes more common.  In particular, it is likely that at
   some point in the future a substantial percentage of all routing
   domains will be attached to public data networks.  In this case,
   nearly all government-sponsored networks (such as some regional
   networks which receive funding from NSF, as well as government
   sponsored backbones) may have a set of customers which overlaps
   substantially with the public networks.

   There are therefore a number of possible solutions to the problem of
   assigning NSAP addresses to multi-homed routing domains.  Each of
   these solutions has very different advantages and disadvantages.
   Each solution places a different real (i.e., financial) cost on the
   multi-homed organizations, and on the providers (including those to
   which the multi-homed organizations are not attached).

   In addition, most of the solutions described also highlight the need
   for each provider to develop policy on whether and under what
   conditions to accept customers with addresses that are not based on
   its own address prefix, and how such non-local addresses will be
   treated.  For example, a somewhat conservative policy might be that
   an attached subscriber RD may use any NSAP address prefix, but that
   addresses which are not based on the providers own prefix might not
   be advertised to other providers.  In a less conservative policy, a
   provider might accept customers using such non-local prefixes and
   agree to exchange them in routing information with a defined set of
   other providers (this set could be an a priori group of providers
   that have something in common such as geographical location, or the
   result of an agreement specific to the requesting subscriber).
   Various policies involve real costs to providers, which may be
   reflected in those policies.

5.5.  Private Links

   The discussion up to this point concentrates on the relationship
   between NSAP addresses and routing between various routing domains
   over transit routing domains, where each transit routing domain
   interconnects a large number of routing domains and offers a more-
   or-less public service.

   However, there may also exist a large number of private point-to-
   point links which interconnect two private routing domains.  In many
   cases such private point-to-point links may be limited to forwarding
   packets directly between the two private routing domains.

   For example, let's suppose that the XYZ corporation does a lot of
   business with MBII.  In this case, XYZ and MBII may contract with a
   carrier to provide a private link between the two corporations, where
   this link may only be used for packets whose source is within one of
   the two corporations, and whose destination is within the other of
   the two corporations.  Finally, suppose that the point-to-point link
   is connected between a single router (router X) within XYZ
   corporation and a single router (router M) within MBII.  It is
   therefore necessary to configure router X to know which addresses can
   be reached over this link (specifically, all addresses reachable in
   MBII).  Similarly, it is necessary to configure router M to know
   which addresses can be reached over this link (specifically, all

   addresses reachable in XYZ Corporation).

   The important observation to be made here is that such private links
   may be ignored for the purpose of NSAP allocation, and do not pose a
   problem for routing.  This is because the routing information
   associated with private links is not propagated throughout the
   internet, and therefore does not need to be collapsed into a
   provider's prefix.

   In our example, lets suppose that the XYZ corporation has a single
   connection to a service provider, and has therefore received an
   address allocation from the space administered by that provider.
   Similarly, let's suppose that MBII, as an international corporation
   with connections to six different providers, has chosen the second
   solution from Section 5.4, and therefore has obtained six different
   address allocations.  In this case, all addresses reachable in the
   XYZ Corporation can be described by a single address prefix (implying
   that router M only needs to be configured with a single address
   prefix to represent the addresses reachable over this point-to-point
   link).  All addresses reachable in MBII can be described by six
   address prefixes (implying that router X needs to be configured with
   six address prefixes to represent the addresses reachable over the
   point-to-point link).

   In some cases, such private point-to-point links may be permitted to
   forward traffic for a small number of other routing domains, such as
   closely affiliated organizations.  This will increase the
   configuration requirements slightly.  However, provided that the
   number of organizations using the link is relatively small, then this
   still does not represent a significant problem.

   Note that the relationship between routing and NSAP addressing
   described in other sections of this paper is concerned with problems
   in scaling caused by large, essentially public transit routing
   domains which interconnect a large number of routing domains.
   However, for the purpose of NSAP allocation, private point-to-point
   links which interconnect only a small number of private routing
   domains do not pose a problem, and may be ignored.  For example, this
   implies that a single subscriber routing domain which has a single
   connection to a "public" provider, plus a number of private point-
   to-point links to other subscriber routing domains, can be treated as
   if it were single-homed to the provider for the purpose of NSAP
   address allocation.

5.6.  Zero-Homed Routing Domains

   Currently, a very large number of organizations have internal
   communications networks which are not connected to any external
   network.  Such organizations may, however, have a number of private
   point-to-point links that they use for communications with other
   organizations.  Such organizations do not participate in global
   routing, but are satisfied with reachability to those organizations
   with which they have established private links.  These are referred
   to as zero-homed routing domains.

   Zero-homed routing domains can be considered as the degenerate case
   of routing domains with private links, as discussed in the previous
   section, and do not pose a problem for inter-domain routing.  As
   above, the routing information exchanged across the private links
   sees very limited distribution, usually only to the RD at the other
   end of the link.  Thus, there are no address abstraction requirements
   beyond those inherent in the address prefixes exchanged across the
   private link.

   However, it is important that zero-homed routing domains use valid
   globally unique NSAP addresses.  Suppose that the zero-homed routing
   domain is connected through a private link to an RD.  Further, this
   RD participates in an internet that subscribes to the global OSI
   addressing plan (i.e., ISO 8348).  This RD must be able to
   distinguish between the zero-homed routing domain's NSAPs and any
   other NSAPs that it may need to route to.  The only way this can be
   guaranteed is if the zero-homed routing domain uses globally unique
   NSAPs.

5.7.  Address Transition Issues

   Allocation of NSAP addresses based on connectivity to providers is
   important to allow scaling of inter-domain routing to an internet
   containing millions of routing domains.  However, such address
   allocation based on topology also implies that a change in topology
   may result in a change of address.

   This need to allow for change in addresses is a natural, inevitable
   consequence of any method for routing data abstraction.  The basic
   notion of routing data abstraction is that there is some
   correspondence between the address and where a system (i.e., a
   routing domain, area, or end system) is located.  Thus if the system
   moves, in some cases the address will have to change.  If it were
   possible to change the connectivity between routing domains without
   changing the addresses, then it would clearly be necessary to keep
   track of the location of that routing domain on an individual basis.

   Because of the rapid growth and increased commercialization of the
   Internet, it is possible that the topology may be relatively
   volatile.  This implies that planning for address transition is very
   important.  Fortunately, there are a number of steps which can be
   taken to help ease the effort required for address transition.  A
   complete description of address transition issues is outside of the
   scope of this paper.  However, a very brief outline of some
   transition issues is contained in this section.

   Also note that the possible requirement to transition addresses based
   on changes in topology imply that it is valuable to anticipate the
   future topology changes before finalizing a plan for address
   allocation.  For example, in the case of a routing domain which is
   initially single-homed, but which is expecting to become multi-homed
   in the future, it may be advantageous to assign NSAP addresses based
   on the anticipated future topology.

   In general, it will not be practical to transition the NSAP addresses
   assigned to a routing domain in an instantaneous "change the address
   at midnight" manner.  Instead, a gradual transition is required in
   which both the old and the new addresses will remain valid for a
   limited period of time.  During the transition period, both the old
   and new addresses are accepted by the end systems in the routing
   domain, and both old and new addresses must result in correct routing
   of packets to the destination.

   Provision for transition has already been built into IS-IS.  As
   described in Section 3, IS-IS allows multiple addresses to be
   assigned to each area specifically for the purpose of easing
   transition.

   Similarly, there are provisions in OSI for the autoconfiguration of
   area addresses.  This allows OSI end systems to find out their area
   addresses automatically, either by passively observing the ES-IS IS-
   Hello packets transmitted by routers, or by actively querying the
   routers for their NSAP address.  If the ID portion of the address is
   assigned in a manner which allows for globally unique IDs [18], then
   an end system can reconfigure its entire NSAP address automatically
   without the need for manual intervention.  However, routers will
   still require manual address reconfiguration.

   During the transition period, it is important that packets using the
   old address be forwarded correctly, even when the topology has
   changed.  This is facilitated by the use of "best match" inter-domain
   routing.

   For example, suppose that the XYZ Corporation was previously
   connected only to the NorthSouthNet provider.  The XYZ Corporation

   therefore went off to the NorthSouthNet administration and got a
   routing domain assignment based on the AA value obtained by the
   NorthSouthNet under the GOSIP address space.  However, for a variety
   of reasons, the XYZ Corporation decided to terminate its association
   with the North-SouthNet, and instead connect directly to the
   NewCommercialNet public data network.  Thus the XYZ Corporation now
   has a new address assignment under the ANSI address assigned to the
   NewCommercialNet.  The old address for the XYZ Corporation would seem
   to imply that traffic for the XYZ Corporation should be routed to the
   NorthSouthNet, which no longer has any direct connection with XYZ
   Corporation.

   If the old provider (NorthSouthNet) and the new provider
   (NewCommercialNet) are adjacent and cooperative, then this transition
   is easy to accomplish.  In this case, packets routed to the XYZ
   Corporation using the old address assignment could be routed to the
   NorthSouthNet, which would directly forward them to the
   NewCommercialNet, which would in turn forward them to XYZ
   Corporation.  In this case only NorthSouthNet and NewCommercialNet
   need be aware of the fact that the old address refers to a
   destination which is no longer directly attached to NorthSouthNet.

   If the old provider and the new provider are not adjacent, then the
   situation is a bit more complex, but there are still several possible
   ways to forward traffic correctly.

   If the old provider and the new provider are themselves connected by
   other cooperative providers, then these intermediate domains may
   agree to forward traffic for XYZ correctly.  For example, suppose
   that NorthSouthNet and NewCommercialNet are not directly connected,
   but that they are both directly connected to the NSFNET backbone.  In
   this case, all three of NorthSouthNet, NewCommercialNet, and the
   NSFNET backbone would need to maintain a special entry for XYZ
   corporation so that traffic to XYZ using the old address allocation
   would be forwarded via NewCommercialNet.  However, other routing
   domains would not need to be aware of the new location for XYZ
   Corporation.

   Suppose that the old provider and the new provider are separated by a
   non-cooperative routing domain, or by a long path of routing domains.
   In this case, the old provider could encapsulate traffic to XYZ
   Corporation in order to deliver such packets to the correct backbone.

   Also, those locations which do a significant amount of business with
   XYZ Corporation could have a specific entry in their routing tables
   added to ensure optimal routing of packets to XYZ.  For example,
   suppose that another commercial backbone "OldCommercialNet" has a
   large number of customers which exchange traffic with XYZ

   Corporation, and that this third provider is directly connected to
   both NorthSouthNet and NewCommercialNet.  In this case
   OldCommercialNet will continue to have a single entry in its routing
   tables for other traffic destined for NorthSouthNet, but may choose
   to add one additional (more specific) entry to ensure that packets
   sent to XYZ Corporation's old address are routed correctly.

   Whichever method is used to ease address transition, the goal is that
   knowledge relating XYZ to its old address that is held throughout the
   global internet would eventually be replaced with the new
   information.  It is reasonable to expect this to take weeks or months
   and will be accomplished through the distributed directory system.
   Discussion of the directory, along with other address transition
   techniques such as automatically informing the source of a changed
   address, are outside the scope of this paper.

6.  Recommendations

   We anticipate that the current exponential growth of the Internet
   will continue or accelerate for the foreseeable future.  In addition,
   we anticipate a continuation of the rapid internationalization of the
   Internet.  The ability of routing to scale is dependent upon the use
   of data abstraction based on hierarchical NSAP addresses.  As CLNP
   use increases in the Internet, it is therefore essential to assign
   NSAP addresses with great care.

   It is in the best interests of the internetworking community that the
   cost of operations be kept to a minimum where possible.  In the case
   of NSAP allocation, this again means that routing data abstraction
   must be encouraged.

   In order for data abstraction to be possible, the assignment of NSAP
   addresses must be accomplished in a manner which is consistent with
   the actual physical topology of the Internet.  For example, in those
   cases where organizational and administrative boundaries are not
   related to actual network topology, address assignment based on such
   organization boundaries is not recommended.

   The intra-domain IS-IS routing protocol allows for information
   abstraction to be maintained at two levels: systems are grouped into
   areas, and areas are interconnected to form a routing domain.  The
   inter-domain IDRP routing protocol allows for information abstraction
   to be maintained at multiple levels by grouping routing domains into
   Routing Domain Confederations and using route aggregation
   capabilities.

   For zero-homed and single-homed routing domains (which are expected
   to remain zero-homed or single-homed), we recommend that the NSAP

   addresses assigned for OSI use within a single routing domain use a
   single address prefix assigned to that domain.  Specifically, this
   allows the set of all NSAP addresses reachable within a single domain
   to be fully described via a single prefix.  We recommend that
   single-homed routing domains use an address prefix based on its
   connectivity to a public service provider.  We recommend that zero-
   homed routing domains use globally unique addresses.

   We anticipate that the total number of routing domains existing on a
   worldwide OSI Internet to be great enough that additional levels of
   hierarchical data abstraction beyond the routing domain level will be
   necessary.  To provide the needed data abstraction we recommend to
   use Routing Domain Confederations and route aggregation capabilities
   of IDRP.

   The general technical requirements for NSAP address guidelines do not
   vary from country to country.  However, details of address
   administration may vary between countries.  Also, in most cases,
   network topology will have a close relationship with national
   boundaries.  For example, the degree of network connectivity will
   often be greater within a single country than between countries.  It
   is therefore appropriate to make specific recommendations based on
   national boundaries, with the understanding that there may be
   specific situations where these general recommendations need to be
   modified.  Moreover, that suggests that national boundaries may be
   used to group domains into Routing Domain Confederations.

   Each of the country-specific or continent-specific recommendations
   presented below are consistent with the technical requirements for
   scaling of addressing and routing presented in this RFC.

6.1.  Recommendations Specific to U.S. Parts of the Internet

   NSAP addresses for use within the U.S. portion of the Internet are
   expected to be based primarily on two address prefixes: the ICD=0005
   format used by The U.S. Government, and the DCC=840 format defined by
   ANSI.

   We anticipate that, in the U.S., public interconnectivity between
   private routing domains will be provided by a diverse set of
   providers, including (but not necessarily limited to) regional
   providers and commercial Public Data Networks.

   These networks are not expected to be interconnected in a strictly
   hierarchical manner.  For example, the regional providers may be
   directly connected rather than rely on an indirect provider, and all
   three of these types of networks may have direct international
   connections.

   However, the total number of such providers is expected to remain
   (for the foreseeable future) small enough to allow addressing of this
   set of providers via a flat address space.  These providers will be
   used to interconnect a wide variety of routing domains, each of which
   may comprise a single corporation, part of a corporation, a
   university campus, a government agency, or other organizational unit.

   In addition, some private corporations may be expected to make use of
   dedicated private providers for communication within their own
   corporations.

   We anticipate that the great majority of routing domains will be
   attached to only one of the providers.  This will permit hierarchical
   address abbreviation based on provider.  We therefore strongly
   recommend that addresses be assigned hierarchically, based on address
   prefixes assigned to individual providers.

   For the GOSIP address format, this implies that Administrative
   Authority (AA) identifiers should be obtained by all providers
   (explicitly including the NSFNET backbone, the NSFNET regionals, and
   other major government backbones).  For those subscriber routing
   domains which are connected to a single provider, they should be
   assigned a Routing Domain (RD) value from the space assigned to that
   provider.

   To provide routing information aggregation/abstraction we recommend
   that each provider together with all of its subscriber domains form a
   Routing Domain Confederation.  That, combined with  hierarchical
   address assignment, would provide significant reduction in the volume
   of routing information that needs to be handled by IDRP.  Note that
   the presence of multihomed subscriber domains would imply that such
   Confederations will overlap, which is explicitly supported by IDRP.

   We recommend that all providers explicitly be involved in the task of
   address administration for those subscriber routing domains which are
   single-homed to them.  This offers a valuable service to their
   customers, and also greatly reduces the resources (including human
   and network resources) necessary for that provider to take part in
   inter-domain routing.

   Each provider should develop policy on whether and under what
   conditions to accept customers using addresses that are not based on
   the provider's own address prefix, and how such non-local addresses
   will be treated.  Policies should reflect the issue of cost
   associated with implementing such policies.

   We recommend that a similar hierarchical model be used for NSAP
   addresses using the DCC-based address format.  The structure for

   DCC=840-based NSAPs is provided in Section A.2.

   For routing domains which are not attached to any publically-
   available provider, no urgent need for hierarchical address
   abbreviation exists.  We do not, therefore, make any additional
   recommendations for such "isolated" routing domains, except to note
   that there is no technical reason to preclude assignment of GOSIP AA
   identifier values or ANSI organization identifiers to such domains.
   Where such domains are connected to other domains by private point-
   to-point links, and where such links are used solely for routing
   between the two domains that they interconnect, no additional
   technical problems relating to address abbreviation is caused by such
   a link, and no specific additional recommendations are necessary.

6.2.  Recommendations Specific to European Parts of the Internet

   This section contains additional RARE recommendations for allocating
   NSAP addresses within each national domain, administered by a
   National Standardization Organization (NSO) and national research
   network organizations.

   NSAP addresses are expected to be based on the ISO DCC scheme.
   Organizations which are not associated with a particular country and
   which have reasons not to use a national prefix based on ISO DCC
   should follow the recommendations covered in chapters 6.3 and 6.4.

   ISO DCC addresses are not associated with any specific subnetwork
   type and service provider and are thus independent of the type or
   ownership of the underlying technology.

6.2.1.  General NSAP Structure

   The general structure of a Network Address defined in ISO 8348 is
   further divided into:

          +-----------+-----------------------------------------+
          |    IDP    |                 DSP                     |
          +-----+-----+-----------+-----------------------------+
          | AFI | IDI |    CDP    |             CDSP            |
          +-----+-----+-----+-----+----------------+------+-----+
          | AFI | IDI | CFI | CDI |      RDAA      |  ID  | SEL |
          +-----+-----+-----+-----+----------------+------+-----+
   octets |  1  |  2  |   2..4    |     0..13      | 1..8 |  1  |
          +-----+-----+-----------+----------------+------+-----+

   IDP    Initial Domain Part
   AFI    Authority and Format Identifier, two-decimal-digit,
          38 for decimal abstract syntax of the DSP or
          39 for binary abstract syntax of the DSP
   IDI    Initial Domain Identifier, a three-decimal-digit
          country code, as defined in ISO 3166
   DSP    Domain Specific Part
   CDP    Country Domain Part, 2..4 octets
   CFI    Country Format Identifier, one digit
   CDI    Country Domain Identifier, 3 to 7 digits, fills
          CDP to an octet boundary
   CDSP   Country Domain Specific Part
   RDAA   Routing Domain and Area Address
   ID     System Identifier (1..8 octet)
   SEL    NSAP Selector

   The total length of an NSAP can vary from 7 to 20 octets.

6.2.2.  Structure of the Country Domain Part

   The CDP identifies an organization within a country and the  CDSP  is
   then available to that organization for further internal structuring
   as it wishes.  Non-ambiguity of addresses is ensured by there being
   the NSO a single national body that allocates the CDPs.

   The CDP is further divided into CFI and CDI, where the CFI identifies
   the format of the CDI.  The importance of this is that it enables
   several types of CDI to be assigned in parallel, corresponding to
   organizations  with different requirements and giving different
   amounts of the total address space to them, and that it conveniently
   enables a substantial amount of address space to be reserved for
   future allocation.

   The possible structures of the CDP are as follows:

   CFI = /0                    reserved
   CFI = /1 CDI = /aaa         very large organizations or
                               trade associations
   CFI = /2 CDI = /aaaaa       organizations of intermediate size
   CFI = /3 CDI = /aaaaaaa     small organizations and single users
   CFI = /4../F                reserved

   Note: this uses the hexadecimal reference publication format defined
   in ISO 8348 of a solidus "/" followed by a string of hexadecimal
   digits.  Each "a" represents a hexadecimal digit.

   Organizations are classified into large, medium and small for the
   purpose of address allocation, and one CFI is made available for each
   category of organization.

   This recommendation for CDP leaves space for the U.S. GOSIP Version 2
   NSAP model (Appendix A.1) by the reserved CFI /8, nevertheless it is
   not recommended for use in the European Internet.

6.2.3.  Structure of the Country Domain Specific Part

   The CDSP must have a structure (within the decimal digit or binary
   octet syntax selected by the AFI value 38 or 39) satisfying both the
   routing requirements (IS-IS) and the logical requirements of the
   organization identified (CFI + CDI).

6.3.  Recommendations Specific to Other Parts of the Internet

   For the part of the Internet which is outside of the U.S. and Europe,
   it is recommended that the DSP format be structured hierarchically
   similarly to that specified within the U.S. and Europe no matter
   whether the addresses are based on DCC or ICD format.

   Further, in order to allow aggregation of NSAPs at national
   boundaries into as few prefixes as possible, we further recommend
   that NSAPs allocated to routing domains should be assigned based on
   each routing domain's connectivity to a national Internet backbone.

6.4.  Recommendations for Multi-Homed Routing Domains

   Some routing domains will be attached to multiple providers within
   the same country, or to providers within multiple countries.  We
   refer to these as "multi-homed" routing domains.  Clearly the strict
   hierarchical model discussed above does not neatly handle such
   routing domains.

   There are several possible ways that these multi-homed routing
   domains may be handled.  Each of these methods vary with respect to
   the amount of information that must be maintained for inter-domain
   routing and also with respect to the inter-domain routes.  In
   addition, the organization that will bear the brunt of this cost
   varies with the possible solutions.  For example, the solutions vary
   with respect to:

   * resources used within routers within the providers;

   * administrative cost on provider personnel; and,

   * difficulty of configuration of policy-based inter-domain
     routing information within subscriber routing domains.

   Also, the solution used may affect the actual routes which packets
   follow, and may effect the availability of backup routes when the
   primary route fails.

   For these reasons it is not possible to mandate a single solution for
   all situations.  Rather, economic considerations will require a
   variety of solutions for different subscriber routing domains and
   providers.

6.5.  Recommendations for RDI and RDCI assignment

   While RDIs and RDCIs need not be related to the set of addresses
   within the domains (confederations) they depict, for the sake of
   simplicity we recommend that RDIs and RDCIs be assigned based on the
   NSAP prefixes assigned to domains and confederations.

   A subscriber RD should use the NSAP prefix assigned to it as its RDI.
   A multihomed RD should use one of the NSAP prefixes assigned to it as
   its RDI.  If a service provider forms a Routing Domain Confederation
   with some of its subscribers and the subscribers take their addresses
   out of the provider, then the NSAP prefix assigned to the provider
   should be used as the RDCI of the confederation.  In this case the
   provider may use a longer NSAP prefix for its own RDIs.  In all other
   cases a provider should use the address prefix that it uses for
   assigning addresses to systems within the provider as its RDI.

7.  Security Considerations

   Security issues are not discussed in this memo (except for the
   discussion of IS-IS authentication in Section 3.2).

8.  Authors' Addresses

   Richard P. Colella
   National Institute of Standards & Technology
   Building 225/Room B217
   Gaithersburg, MD 20899

   Phone: (301) 975-3627
   EMail:  colella@nist.gov


   Ross Callon
   c/o Wellfleet Communications, Inc
   2 Federal Street
   Billerica, MA 01821

   Phone: (508) 436-3936
   EMail:  callon@wellfleet.com


   Ella P. Gardner
   The MITRE Corporation
   7525 Colshire Drive
   McLean, VA 22102-3481

   Phone: (703) 883-5826
   EMail:  epg@gateway.mitre.org


   Yakov Rekhter
   T.J. Watson Research Center, IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY 10598

   Phone: (914) 945-3896
   EMail: yakov@watson.ibm.com

9.  Acknowledgments

   The authors would like to thank the members of the IETF OSI-NSAP
   Working Group and of RARE WG4 for the helpful suggestions made during
   the writing of this paper.  We would also like to thank Radia Perlman
   of Novell, Marcel Wiget of SWITCH, and Cathy Wittbrodt of BARRnet for
   their ideas and help.

10.  References

   [1] ANSI, "American National Standard for the Structure and Semantics
       of the Domain-Specific Part (DSP) of the OSI Network Service
       Access Point (NSAP) Address", American National Standard X3.216-
       1992.

   [2] Boland, T., "Government Open Systems Interconnection Profile
       Users' Guide Version 2 (DRAFT)", NIST Special Publication,
       National Institute of Standards and Technology, Computer Systems
       Laboratory, Gaithersburg, MD, June 1991.

   [3] GOSIP Advanced Requirements Group, "Government Open Systems
       Interconnection Profile (GOSIP) Version 2", Federal Information
       Processing Standard 146-1, U.S. Department of Commerce, National
       Institute of Standards and Technology, Gaithersburg, MD, April
       1991.

   [4] Hemrick, C., "The OSI Network Layer Addressing Scheme, Its
       Implications, and Considerations for Implementation", NTIA Report
       85186, U.S. Department of Commerce, National Telecommunications
       and Information Administration, 1985.

   [5] ISO, "Addendum to the Network Service Definition Covering Network
       Layer Addressing," RFC 941, ISO, April 1985.

   [6] ISO/IEC, "Codes for the Representation of Names of Countries",
       International Standard 3166, ISO/IEC JTC 1, Switzerland, 1984.

   [7] ISO/IEC, "Data Interchange - Structures for the Identification of
       Organization", International Standard 6523, ISO/IEC JTC 1,
       Switzerland, 1984.

   [8] ISO/IEC, "Information Processing Systems - Open Systems
       Interconnection -- Basic Reference Model", International Standard
       7498, ISO/IEC JTC 1, Switzerland, 1984.

   [9] ISO/IEC, "Protocol for Providing the Connectionless-mode Network
       Service", International Standard 8473, ISO/IEC JTC 1,
       Switzerland, 1986.

  [10] ISO/IEC, "End System to Intermediate System Routing Exchange
       Protocol for use in Conjunction with the Protocol for the
       Provision of the Connectionless-mode Network Service",
       International Standard 9542, ISO/IEC JTC 1, Switzerland, 1987.

  [11] ISO/IEC, "Information Processing Systems -- Data Communications
       -- Network Service Definition", International Standard 8348,
       1992.

  [12] ISO/IEC, "Information Processing Systems - OSI Reference Model -
       Part3: Naming and Addressing", Draft International Standard
       7498-3, ISO/IEC JTC 1, Switzerland, March 1989.

  [13] ISO/IEC, "Information Technology - Telecommunications and
       Information Exchange Between Systems - OSI Routeing Framework",
       Technical Report 9575, ISO/IEC JTC 1, Switzerland, 1989.

  [14] ISO/IEC, "Intermediate System to Intermediate System Intra-Domain
       Routeing Exchange Protocol for use in Conjunction with the
       Protocol for Providing the Connectionless-Mode Network Service
       (ISO 8473)", International Standard ISO/IEC 10589, 1992.

  [15] Loughheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
       (BGP-3)"  RFC 1267, cisco Systems, T.J. Watson Research Center,
       IBM Corp., October 1991.

  [16] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing
       Information among Intermediate Systems to support Forwarding of
       ISO 8473 PDUs", International Standard 10747, ISO/IEC JTC 1,
       Switzerland 1993.

  [17] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
       Proposal for Internet Addressing and Routing", RFC 1347, DEC,
       June 1992.

  [18] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP
       Hosts", RFC 1526, Bellcore, September 1993.

  [19] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
       Domain Routing (CIDR): an Address Assignment and Aggregation
       Strategy", RFC 1519, BARRNet, cisco, OARnet, September 1993.

  [20] ISO/IEC JTC1/SC6, "Addendum to ISO 9542 Covering Address
       Administration", N6273, March 1991.

A.  Administration of NSAPs

   NSAPs represent the endpoints of communication through the Network
   Layer and must be globally unique [4].  ISO 8348 defines the
   semantics of the NSAP and the abstract syntaxes in which the
   semantics of the Network address can be expressed [11].

   The NSAP consists of the initial domain part (IDP) and the domain
   specific part (DSP).  The initial domain part of the NSAP consists of
   an authority and format identifier (AFI) and an initial domain
   identifier (IDI).  The AFI specifies the format of the IDI, the
   network addressing authority responsible for allocating values of the
   IDI, and the abstract syntax of the DSP.  The IDI specifies the
   addressing subdomain from which values of the DSP are allocated and
   the network addressing authority responsible for allocating values of
   the DSP from that domain.  The structure and semantics of the DSP are
   determined by the authority identified by the IDI.  Figure 3 shows
   the NSAP address structure.

     +-----------+
     |   IDP     |
     +-----+-----+-------------------------------------------------+
     | AFI | IDI |<--------------------DSP------------------------>|
     +-----+-----+-------------------------------------------------+

              IDP  Initial Domain Part
              AFI  Authority and Format Identifier
              IDI  Initial Domain Identifier
              DSP  Domain Specific Part

              Figure 3: NSAP address structure.

   The global network addressing domain consists of all the NSAP
   addresses in the OSI environment.  Within that environment, seven
   second-level addressing domains and corresponding IDI formats are
   described in ISO 8348:

      * X.121 for public data networks

      * F.69 for telex

      * E.163 for the public switched telephone network numbers

      * E.164 for ISDN numbers

      * ISO Data Country Code (DCC), allocated according to ISO 3166 [6]

      * ISO International Code Designator (ICD), allocated according to
        ISO 6523 [7]

      * Local to accommodate the coexistence of OSI and non-OSI network
        addressing schemes.

   For OSI networks in the U.S., portions of the ICD subdomain are
   available for use through the U.S. Government, and the DCC subdomain
   is available for use through The American National Standards
   Institute (ANSI).  The British Standards Institute is the
   registration authority for the ICD subdomain, and has registered four
   IDIs for the U.S. Government: those used for GOSIP, DoD, OSINET, and
   the OSI Implementors Workshop.  ANSI, as the U.S. ISO Member Body, is
   the registration authority for the DCC domain in the United States.

A.1  GOSIP Version 2 NSAPs

   GOSIP Version 2 makes available for government use an NSAP addressing
   subdomain with a corresponding address format as illustrated in
   Figure 2 in Section 4.2.  The "47" signifies that it is based on the
   ICD format and uses a binary syntax for the DSP.  The 0005 is an IDI
   value which has been assigned to the U.S. Government.  Although GOSIP
   Version 2 NSAPs are intended primarily for U.S. Government use,
   requests from non-government and non-U.S. organizations will be
   considered on a case-by-case basis.

   The format for the DSP under ICD=0005 has been established by the
   National Institute of Standards and Technology (NIST), the authority
   for the ICD=0005 domain, in GOSIP Version 2 [3] (see Figure 2,
   Section 4.2).  NIST has delegated the authority to register AA
   identifiers for GOSIP Version 2 NSAPs to the General Services
   Administration (GSA).

   ISO 8348 allows a maximum length of 20 octets for the NSAP address.
   The AFI of 47 occupies one octet, and the IDI of 0005 occupies two
   octets.  The DSP is encoded as binary as indicated by the AFI of 47.
   One octet is allocated for a DSP Format Identifier, three octets for
   an Administrative Authority identifier, two octets for Routing
   Domain, two octets for Area, six octets for the System Identifier,
   and one octet for the NSAP selector.  Note that two octets have been
   reserved to accommodate future growth and to provide additional
   flexibility for inter-domain routing.  The last seven octets of the
   GOSIP NSAP format are structured in accordance with IS-IS [14], the
   intra-domain IS-IS routing protocol.  The DSP Format Identifier (DFI)
   identifies the format of the remaining DSP structure and may be used
   in the future to identify additional DSP formats; the value 80h in
   the DFI identifies the GOSIP Version 2 NSAP structure.

   The Administrative Authority identifier names the administrative
   authority which is responsible for registration within its domain.
   The administrative authority may delegate the responsibilityfor
   registering areas to the routing domains, and the routing domains may
   delegate the authority to register System Identifiers to the areas.
   The main responsibility of a registration authority at any level of
   the addressing hierarchy is to assure that names of entities are
   unambiguous, i.e., no two entities have the same name.  The
   registration authority is also responsible for advertising the names.

   A routing domain is a set of end systems and intermediate systems
   which operate according to the same routing procedures and is wholly
   contained within a single administrative domain.  An area uniquely
   identifies a subdomain of the routing domain.  The system identifier
   names a unique system within an area.  The value of the system field
   may be a physical address (SNPA) or a logical value.  Address
   resolution between the NSAP and the SNPA may be accomplished by an
   ES-IS protocol [10],  locally administered tables, or mapping
   functions.  The NSAP selector field identifies the end user of the
   network layer service, i.e., a transport layer entity.

A.1.1  Application for Administrative Authority Identifiers

   The steps required for an agency to acquire an NSAP Administrative
   Authority identifier under ICD=0005 from GSA will be provided in the
   updated GOSIP users' guide for Version 2 [2] and are given below.
   Requests from non-government and non-U.S. organizations should
   originate from a senior official, such as a vice-president or chief
   operating officer.

      * Identify all end systems, intermediate systems, subnetworks, and
        their topological and administrative relationships.

      * Designate one individual (usually the agency head) within an
        agency to authorize all registration requests from that agency
        (NOTE: All agency requests must pass through this individual).

      * Send a letter on agency letterhead and signed by the agency head
        to GSA:

               Telecommunications Customer Requirements Office
               U.S. General Services Administration
               Information Resource Management Service
               Office of Telecommunications Services
               18th and F Streets, N.W.
               Washington, DC 20405
               Fax +1 202 208-5555

        The letter should contain the following information:

          - Requestor's Name and Title,

          - Organization,

          - Postal Address,

          - Telephone and Fax Numbers,

          - Electronic Mail Address(es), and,

          - Reason Needed (one or two paragraphs explaining the intended
            use).

      * If accepted, GSA will send a return letter to the agency head
        indicating the NSAP Administrative Authority identifier as-
        signed,effective date of registration, and any other pertinent
        information.

      * If rejected, GSA will send a letter to the agency head
        explaining the reason for rejection.

      * Each Authority will administer its own subaddress space in
        accordance with the procedures set forth by the GSA in Section
        A.1.2.

      * The GSA will maintain, publicize, and disseminate the assigned
        values of Administrative Authority identifiers unless
        specifically requested by an agency not to do so.

A.1.2 Guidelines for NSAP Assignment

   Recommendations which should be followed by an administrative
   authority in making NSAP assignments are given below.


      * The authority should determine the degree of structure of the
        DSP under its control.  Further delegation of address assignment
        authority (resulting in additional levels of hierarchy in the
        NSAP) may be desired.

      * The authority should make sure that portions of NSAPs that it
        specifies are unique, current, and accurate.

      * The authority should ensure that procedures exist for
        disseminating NSAPs to routing domains and to areas within
        each routing domain.

      * The systems administrator must determine whether a logical or a
        physical address should be used in the System Identifier field
        (Figure 2, Section 4.2).  An example of a physical address is a
        48-bit MAC address; a logical address is merely a number that
        meets the uniqueness requirements for the System Identifier
        field, but bears no relationship to an address on a physical
        subnetwork.  We recommend that IDs should be assigned to be
        globally unique, as made possible by the method described in
        [18].

      * The network address itself contains information that may be
        used to aid routing, but does not contain a source route [12].
        Information that enables next-hop determination based on NSAPs
        is gathered and maintained by each intermediate system through
        routing protocol exchanges.

      * GOSIP end systems and intermediate systems in federal agencies
        must be capable of routing information correctly to and from any
        subdomain defined by ISO 8348.

      * An agency may request the assignment of more than one
        Administrative Authority identifier.  The particular use of each
        should be specified.

A.2  Data Country Code NSAPs

   NSAPs from the Data Country Code (DCC) subdomain will also be common
   in the international Internet.  ANS X3.216-1992 specifies the DSP
   structure under DCC=840 [1].  In the ANS, the DSP structure is
   identical to that specified in GOSIP Version 2, with the

   Administrative Authority identifier replaced by the numeric form of
   the ANSI-registered organization name, as shown in Figure 4.

   Referring to Figure 4, when the value of the AFI is 39, the IDI
   denotes an ISO DCC and the abstract syntax of the DSP is binary
   octets.  The value of the IDI for the U.S. is 840, the three-digit
   numeric code for the United States under ISO 3166 [6].  The numeric
   form of organization name is analogous to the Administrative
   Authority identifier in the GOSIP Version 2 NSAP.

          <----IDP--->
          +-----+-----+----------------------------------------+
          | AFI | IDI |<----------------------DSP------------->|
          +-----+-----+----------------------------------------+
          | 39  | 840 | DFI |ORG | Rsvd | RD | Area | ID | SEL |
          +-----+-----+----------------------------------------+
   octets |  1  |  2  |  1  | 3  |   2  | 2  |  2   | 6  |  1  |
          +-----+-----+----------------------------------------+

              IDP   Initial Domain Part
              AFI   Authority and Format Identifier
              IDI   Initial Domain Identifier
              DSP   Domain Specific Part
              DFI   DSP Format Identifier
              ORG   Organization Name (numeric form)
              Rsvd  Reserved
              RD    Routing Domain Identifier
              Area  Area Identifier
              ID    System Identifier
              SEL   NSAP Selector

        Figure 4: NSAP format for DCC=840 as proposed in ANSI X3S3.3.

A.2.1  Application for Numeric Organization Name

   The procedures for registration of numeric organization names in the
   U.S. have been defined and are operational.  To register a numeric
   organization name, the applicant must submit a request for
   registration and the $1,000 (U.S.) fee to the registration authority,
   the American National Standards Institute (ANSI).  ANSI will register
   a numeric value, along with the information supplied for
   registration, in the registration database.  The registration
   information will be sent to the applicant within ten working days.
   The values for numeric organization names are assigned beginning at
   113527.

   The application form for registering a numeric organization name may
   be obtained from the ANSI Registration Coordinator at the following
   address:

              Registration Coordinator
              American National Standards Institute
              11 West 42nd Street
              New York, NY 10036
              +1 212 642 4884 (tel)
              +1 212 398 0023 (fax)
              RFC822: mmaas@attmail.com
              X.400: G=michelle; S=maas; A=attmail; C=us

   Once an organization has registered with ANSI, it becomes a
   registration authority itself. In turn, it may delegate registration
   authority to routing domains, and these may make further delegations,
   for instance,  from routing domains to areas.  Again, the
   responsibilities of each Registration Authority are to assure that
   NSAPs within the domain are unambiguous and to advertise them as
   applicable.

A.3  Summary of Administrative Requirements

   NSAPs must be globally unique, and an organization may assure this
   uniqueness for OSI addresses in two ways.  The organization may apply
   to GSA for an Administrative Authority identifier.  Although
   registration of Administrative Authority identifiers by GSA primarily
   serves U.S. Government agencies, requests for non-government and
   non-U.S.  organizations will be considered on a case-by-case basis.
   Alternatively, the organization may apply to ANSI for a numeric
   organization name.  In either case, the organization becomes the
   registration authority for its domain and can register NSAPs or
   delegate the authority to do so.

   In the case of GOSIP Version 2 NSAPs, the complete DSP structure is
   given in GOSIP Version 2.  For ANSI DCC-based NSAPs, the DSP
   structure is specified in ANS X3.216-1992.  The DSP structure is
   identical to that specified in GOSIP Version 2.