GSA (implying that the first four octets of the address would be
those assigned out of the GOSIP space), or based on an RD value from
its provider (implying that the first seven octets of the address are
those obtained by that provider). If considering only their own
self-interest, the subscriber and its local provider have little
reason to choose one approach or the other. The subscriber must use
one prefix or another; the source of the prefix has little effect on
routing efficiency within the subscriber's routing domain. The
provider must maintain information about each attached subscriber in
order to route, regardless of any commonality in the prefixes of its
subscribers.
However, there is a difference when the local provider distributes
routing information to other providers. In the first case, the
provider cannot aggregate the subscriber's address into its own
prefix; the address must be explicitly listed in routing exchanges,
resulting in an additional burden to other providers which must
exchange and maintain this information.
In the second case, each other provider sees a single address prefix
for the local provider which encompasses the new subscriber. This
avoids the exchange of additional routing information to identify the
new subscriber's address prefix. Thus, the advantages primarily
benefit other providers which maintain routing information about this
provider (and its subscribers).
Clearly, a symmetric application of these principles is in the
interest of all providers, enabling them to more efficiently support
CLNP routing to their customers. The guidelines discussed below
describe reasonable ways of managing the OSI address space that
benefit the entire community.
5.1. Administration at the Area
If areas take their area addresses from a myriad of unrelated NSAP
allocation authorities, there will be effectively no data abstraction
beyond what is built into IS-IS. For example, assume that within a
routing domain three areas take their area addresses, respectively,
out of:
* the GOSIP Version 2 authority assigned to the Department
of Commerce, with an AA of nnn:
AFI=47, IDI=0005, DFI=80h, AA=nnn, ... ;
* the GOSIP Version 2 authority assigned to the Department
of the Interior, with an AA of mmm:
AFI=47, IDI=0005, DFI=80h, AA=mmm, ... ; and,
* the ANSI authority under the U.S. Data Country Code (DCC)
(Section A.2) for organization XYZ with ORG identifier = xxx:
AFI=39, IDI=840, DFI=dd, ORG=xxx, ....
As described in Section 3.3, from the point of view of any particular
routing domain, there is no harm in having the different areas in the
routing domain use addresses obtained from a wide variety of
administrations. For routing within the domain, the area addresses
are treated as a flat field.
However, this does have a negative effect on inter-domain routing,
particularly on those other domains which need to maintain routes to
this domain. There is no common prefix that can be used to represent
these NSAPs and therefore no summarization can take place at the
routing domain boundary. When addresses are advertised by this
routing domain to other routing domains, an enumerated list must be
used consisting of the three area addresses.
This situation is roughly analogous to the dissemination of routing
information in the TCP/IP Internet prior to the introduction of CIDR.
Areas correspond roughly to networks and area addresses to network
numbers. The result of allowing areas within a routing domain to
take their NSAPs from unrelated authorities is flat routing at the
area address level. The number of address prefixes that subscriber
routing domains would advertise is on the order of the number of
attached areas; the number of prefixes a provider routing domain
would advertise is approximately the number of areas attached to all
its subscriber routing domains. For "default-less" providers (i.e.,
those that don't use default routes) the size of the routing tables
would be on the order of the number of area addresses globally. As
the CLNP internet grows this would quickly become intractable. A
greater degree of hierarchical information reduction is necessary to
allow greater growth.
5.2. Administration at the Subscriber Routing Domain
As mentioned previously, the greatest degree of data abstraction
comes at the lowest levels of the hierarchy. Providing each
subscriber routing domain (that is, site) with a unique prefix
results in the biggest single increase in abstraction, with each
subscriber domain assigning area addresses from its prefix. From
outside the subscriber routing domain, the set of all addresses
reachable in the domain can then be represented by a single prefix.
As an example, assume a government agency has been assigned the AA
value of zzz under ICD=0005. The agency then assigns a routing
domain identifier to a routing domain under its administrative
authority identifier, rrr. The resulting prefix for the routing
domain is:
AFI=47, IDI=0005, DFI=80h, AA=zzz, (Rsvd=0), RD=rrr.
All areas within this routing domain would have area addresses
comprising this prefix followed by an Area identifier. The prefix
represents the summary of reachable addresses within the routing
domain.
There is a close relationship between areas and routing domains
implicit in the fact that they operate a common routing protocol and
are under the control of a single administration. The routing domain
administration subdivides the domain into areas and structures a
level 2 subdomain (i.e., a level 2 backbone) which provides
connectivity among the areas. The routing domain represents the only
path between an area and the rest of the internetwork. It is
reasonable that this relationship also extend to include a common
NSAP addressing authority. Thus, the areas within the subscriber RD
should take their NSAPs from the prefix assigned to the subscriber
RD.
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.