regionals, leaf routing domains directly attached to the backbones,
and international links directly attached to the regionals. Under
these circumstances, the distinction between regionals and backbones
may become blurred.
An additional factor that discourages allocation of NSAPs from a
backbone prefix is that the backbones and their attached regionals are
perceived as being independent. Regionals may take their long-haul
service from one or more backbones, or may switch backbones should
a more cost-effective service be provided elsewhere (essentially,
backbones can be thought of the same way as long-distance telephone
carriers). Having NSAPs derived from the backbone is inconsistent with
the nature of the relationship.
Colella, Gardner, & Callon [Page 23]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
5.4 Multi-homed Routing Domains
The discussions in Section 5.3 suggest methods for allocating NSAP
addresses based on regional or backbone connectivity. This allows a
great deal of information reduction to be achieved for those routing
domains which are attached to a single TRD. In particular, such
routing domains may select their NSAP addresses from a space allocated
to them by the regional. This allows the regional, when announcing the
addresses that it can reach to other regionals and backbones, 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 regionals and backbones. Such ``multi-
homed'' routing domains may, for example, consist of single-site
campuses and companies which are attached to multiple backbones, large
organizations which are attached to different regionals at different
locations in the same country, or multi-national organizations which
are attached to backbones 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 regionals and backbones 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 TRD, the TRDs to which this organization is attached will
need to advertise the prefix for this organization to other regionals
and backbones. Other regionals and backbones (potentially worldwide)
will need to maintain an explicit entry for that organization in their
routing tables.
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 backbone and regional
will need to maintain a separate address entry for MBII. If MBII
Colella, Gardner, & Callon [Page 24]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
is in fact an international corporation, then it may be necessary
for every backbone worldwide to maintain a separate entry for MBII
(including backbones to which MBII is not attached). Clearly this
may be acceptable if there are a small number of such multi-homed
routing domains, but would place an unacceptable load on routers
within backbones 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 TRD, 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 regionals in the U.S. (one east coast, and
one west coast), as well as three connections to national backbones
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 TRD which has a connection to MBII needs
to announce to other TRDs 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
TRDs, resulting in a smaller load on the inter-domain routing tables
maintained by TRDs 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 TRD, 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 TRD 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 TRD
Colella, Gardner, & Callon [Page 25]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
were severed, then the NSAPs within MBII with addresses based on that
TRD 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 TRDs).
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 TRD. Other TRDs to which the multi-homed
organization are attached maintain a routing table entry for the
organization, but are extremely selective in terms of which other
TRDs are told of this route. This approach will produce a single
``default'' routing entry which all TRDs will know how to reach
Colella, Gardner, & Callon [Page 26]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
(since presumably all TRDs will maintain routes to each other), while
providing more direct routing in some cases.
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 TRDs (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 TRDs (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 worldwide TRDs
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 TRDs, 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 precisely two (or more)
specific routing domains. For example, suppose that there are two
regionals ``SouthNorthNet'' and ``NorthSouthNet'' which have a very
Colella, Gardner, & Callon [Page 27]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
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 TRDs would then advertise two prefixes to other
TRDs, one prefix for leaf routing domains attached to it only, and one
prefix for leaf routing domains attached to both.
This fourth solution is likely to be 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 current NSFNET regionals)
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 TRDs (including those to which
the multi-homed organizations are not attached).
In addition, most of the solutions described also highlight the need
for each TRD to develop policy on whether and under what conditions
to accept 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 non-local NSAP prefixes will be
accepted from any attached leaf RD, but not advertised to other TRDs.
In a less conservative policy, a TRD might accept such non-local
prefixes and agree to exchange them with a defined set of other TRDs
(this set could be an a priori group of TRDs that have something in
common such as geographical location, or the result of an agreement
specific to the requesting leaf RD). Various policies involve real
costs to TRDs, which may be reflected in those policies.
Colella, Gardner, & Callon [Page 28]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
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 TRD's
prefix.
In our example, lets suppose that the XYZ corporation has a single
connection to an NSFNET regional, and has therefore received an
address allocation from the space administered by that regional.
Similarly, let's suppose that MBII, as an international corporation
with connections to six different backbones or regionals, 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
Colella, Gardner, & Callon [Page 29]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
(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 leaf routing domain which has a single connection to a
``public'' backbone (e.g., the NSFNET), plus a number of private
point-to-point links to other leaf routing domains, can be treated
as if it were single-homed to the backbone 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,
Colella, Gardner, & Callon [Page 30]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
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., Addendum 2 to ISO8348). 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 Transition Issues
Allocation of NSAP addresses based on connectivity to TRDs 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 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.
In the short term, due to the rapid growth and increased commer-
cialization 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.
Colella, Gardner, & Callon [Page 31]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
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 DIS10589.
As described in Section 3, DIS10589 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 by observing the ISO9542 IS-Hello packets
transmitted by routers. If the ID portion of the address is assigned
by using IEEE style ``stamped in PROM at birth'' identifiers, then
an end system can reconfigure its entire NSAP address automatically
without the need for manual intervention. However, routers will still
need 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 NSFNET regional. The XYZ Corporation
therefore went off to the NorthSouthNet administration and got a
routing domain assignment based on the AA value assigned to the
NorthSouthNet regional under the GOSIP address space. However, for
a variety of reasons, the XYZ Corporation decided to terminate its
association with the NorthSouthNet, and instead connect directly to
Colella, Gardner, & Callon [Page 32]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
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 TRD (NorthSouthNet) and the new TRD (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 TRD and the new TRD 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 TRD and the new TRD are themselves connected by other
cooperative transit routing domains, 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 TRD and the new TRD are separated by a non-
cooperative routing domain, or by a long path of routing domains. In
this case, the old TRD 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,
Colella, Gardner, & Callon [Page 33]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
and that this third TRD 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 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 OSI is introduced in the
Internet, it is therefore essential to choose a hierarchical structure
for 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
Colella, Gardner, & Callon [Page 34]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
into areas, and areas are interconnected to form a routing domain.
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 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.
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.
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 IDP format
used by NIST for GOSIP Version 2, 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 TRDs,
including (but not necessarily limited to):
* the NSFNET backbone;
* a number of NSFNET regional networks; and,
* a number of commercial Public Data Networks.
It is also expected that these networks will not be interconnected
in a strictly hierarchical manner (for example, there is expected
to be direct connectivity between NSFNET regionals, and all three of
these types of networks may have direct international connections).
Colella, Gardner, & Callon [Page 35]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
However, the total number of such TRDs is expected to remain (for the
foreseeable future) small enough to allow addressing of this set of
TRDs via a flat address space. These TRDs 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 TRDs for communication within their own corporation.
We anticipate that the great majority of routing domains will be
attached to only one of the TRDs. This will permit hierarchical
address abbreviation based on TRD. We therefore strongly recommend
that addresses be assigned hierarchically, based on address prefixes
assigned to individual TRDs.
For the GOSIP address format, this implies that Administrative
Authority (AA) identifiers should be assigned to all TRDs (explicitly
including the NSFNET backbone, the NSFNET regionals, and other major
government backbones). For those leaf routing domains which are
connected to a single TRD, they should be assigned a Routing Domain
(RD) value from the space assigned to that TRD.
We recommend that all TRDs explicitly be involved in the task of
address administration for those leaf routing domains which are
single-homed to them. This will offer a valuable service to their
customers, and will also greatly reduce the resources (including
human and network resources) necessary for that TRD to take part in
inter-domain routing.
Each TRD should develop policy on whether and under what conditions to
accept addresses that are not based on its 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 TRD, there is not the same urgent need for hierarchical
address abbreviation. We do not, therefore, make any additional
recommendations for such ``isolated'' routing domains, except to
Colella, Gardner, & Callon [Page 36]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
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, again 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 Non-U.S. Parts of the Internet
For the part of the Internet which is outside of the U.S., it is
recommended that the DSP format be structured similarly to that
specified within GOSIP Version 2 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.3 Recommendations for Multi-Homed Routing Domains
Some routing domains will be attached to multiple TRDs within the
same country, or to TRDs within multiple different 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 TRDs;
* administrative cost on TRD personnel; and,
Colella, Gardner, & Callon [Page 37]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
* difficulty of configuration of policy-based inter-domain routing
information within leaf 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 routing domains, regionals, and backbones.
7 Security Considerations
Security issues are not discussed in this memo.
Colella, Gardner, & Callon [Page 38]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
8 Authors' Addresses
Richard P. Colella
National Institute of Standards & Technology
Building 225/Room B217
Gaithersburg, MD 20899
Phone: (301) 975-3627
EMail: colella@osi3.ncsl.nist.gov
EllaP. Gardner
The MITRE Corporation
7525 Colshire Drive
McLean, VA 22102
Phone: (703) 883-5826
EMail: epg@gateway.mitre.org
Ross Callon
c/o Digital Equipment Corporation, 1-2/A19
550 King Street
Littleton, MA 01460-1289
Phone: (508) 486-5009
Email: Callon@bigfut.enet.dec.com
9 Acknowledgments
The authors would like to thank the members of the IETF OSI-NSAP
Working Group for the helpful suggestions made during the writing of
this paper.
Colella, Gardner, & Callon [Page 39]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
A Administration of NSAPs
NSAPs represent the endpoints of communication through the Network
Layer and must be globally unique [5]. Addendum 2 to ISO8348 defines
the semantics of the NSAP and the abstract syntaxes in which the
semantics of the Network address can be expressed [14].
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 ISO8348/Addendum 2:
* 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 ISO3166 [9]
Colella, Gardner, & Callon [Page 40]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
* ISO International Code Designator (ICD), allocated according to
ISO6523 [10]
* 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 subdo-
main 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. (The
U.S. Government is registered as an organization by ANSI under the
DCC, and in turn, will register object identifiers and X.400 names
under this authority.)
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 on page 16. 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 [4] (see Figure 2,
page 16). NIST has delegated the authority to register AA identifiers
for GOSIP Version 2 NSAPs to the General Services Administration
(GSA).
Addendum 2 to ISO8348 allows a maximum length of 20 octets for the
NSAP. 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
Colella, Gardner, & Callon [Page 41]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
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 DIS10589 [17], 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 responsibility for
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 [13], 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.
Colella, Gardner, & Callon [Page 42]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
* 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 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.
Colella, Gardner, & Callon [Page 43]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
* 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 dissemi-
nating 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
(Figure2, page 16). 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.
* The network address itself contains no routing information [15].
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 ISO8348/Addendum 2.
* An agency may request the assignment of more than one Administra-
tive Authority identifier. The particular use of each should be
specified.
Colella, Gardner, & Callon [Page 44]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991