rfc-1629

Guidelines for OSI NSAP Allocation in the Internet

R. Colella, R. Callon, E. Gardner, Y. Rekhter
date1994-05 streamIETF areaosi wgosinsap statusDRAFT STANDARD pages52 canonicalhttps://www.rfc-editor.org/rfc/rfc1629 doi10.17487/RFC1629
This paper provides guidelines for allocating NSAP addresses in the Internet. The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration. [STANDARDS-TRACK]

obsoletes

Extracted elements (25)

design-rationale §5.7

Address transition must be gradual rather than instantaneous. IS-IS explicitly supports multiple simultaneous area addresses per area so a routing domain can operate with both old and new addresses valid concurrently during a transition period, enabling graceful migration, area merges, and area splits without disrupting routing.

routing

design-rationale §5.1

Areas within a routing domain should draw NSAP addresses from a common prefix owned by the routing domain rather than from multiple unrelated authorities. Using unrelated authorities produces no common prefix, forcing enumeration of all area addresses at routing domain boundaries — analogous to pre-CIDR IP routing — and prevents scalable hierarchical summarization.

routing

design-rationale §5.3.2

Direct service providers should not derive their address space from indirect providers (backbones), because the relationship between direct and indirect providers is inherently independent — direct providers may switch backbones — and the routing data abstraction benefit is small given the current order-of-magnitude count of direct providers.

routing

design-rationale §5.4

Multi-homed routing domains face a fundamental trade-off across at least four solutions: (1) provider-independent addressing requires worldwide per-organization routing entries; (2) per-provider addressing scales well but lacks automatic backup and requires renumbering on topology change; (3) single-provider-based addressing with selective advertisement; and (4) shared-prefix assignment for cooperative multi-provider groups.

routing

design-rationale §1

NSAP addresses (20 octets) provide considerably greater flexibility and scalability than IPv4 CIDR addresses (4 octets). The larger address space enables deeper hierarchical allocation, more levels of data abstraction, and is expected to support tens or hundreds of thousands of routing domains in the U.S. alone, whereas flat inter-domain routing becomes intractable at that scale.

routing, ip

design-rationale §5.5

Private point-to-point links between routing domains can be ignored for NSAP allocation purposes because their routing information is not propagated throughout the internet. A subscriber with a single public provider connection plus multiple private links may be treated as single-homed for NSAP allocation, simplifying address administration.

routing

design-rationale §5.3.1

Subscriber routing domains should obtain NSAP prefixes from their direct service provider rather than from independent administrative authorities such as GSA or ANSI. Provider-assigned prefixes allow the provider to advertise a single aggregated prefix to other providers, avoiding per-subscriber routing table entries at every other provider worldwide.

routing

interoperability-note §3.2

IS-IS allows an area to carry multiple area addresses simultaneously to support graceful address changes, area merges, and area splits. A Level 1 IS accepts a neighbor if any area addresses overlap, enabling incremental migration where both old and new addresses remain valid until all nodes have transitioned.

routing

interoperability-note §4.2

The GOSIP Version 2 format (AFI=47, IDI=0005) and the ANSI ISO-DCC format (AFI=39, IDI=840) for U.S. organizations use an identical DSP structure; technical considerations for NSAP administration are independent of which format is used. Both work equally well for routing, differing only in the registration authority (GSA vs. ANSI).

routing

normative-requirement §3.4 SHOULD

A system shall be able to generate and forward data packets containing addresses in any format specified by ISO 8348. Within an IS-IS routing domain, the lower-order octets of the NSAP should be structured as ID and SEL fields; end systems that do not conform may require additional manual configuration and are subject to inferior routing performance.

routing

normative-requirement §3.3 SHOULD

An NSAP prefix carried in the NLRI field for a route originated by a BIS in a given routing domain should be associated with only that routing domain. Ambiguous routing may result if multiple routing domains originate routes with identical NSAP address prefixes, implying the same system is simultaneously in several routing domains.

routing

normative-requirement §3.3 REQUIRED

IDRP requires a BIS to be preconfigured with the RDI of its domain. If the domain belongs to one or more RDCs, the BIS must also be preconfigured with the RDCIs of all those RDCs and with information about their relationships (nested or overlapped).

routing

normative-requirement §3.4 MUST

The area address (concatenation of IDP and HO-DSP) must be globally unique. If the area address of an NSAP matches one of the area addresses of a router, the destination is in the router's area and is routed to by Level 1 routing.

routing

normative-requirement §3.4 MUST

The ID field must be unique within an area for end systems and Level 1 ISs, and unique within the routing domain for Level 2 ISs. The ID field is assumed to be flat; RFC 1526 may optionally be used to assure globally unique IDs.

routing

normative-requirement §5.6 MUST

Zero-homed routing domains must use valid globally unique NSAP addresses. A routing domain connected via private link to a participant in the global OSI addressing plan (ISO 8348) must be able to distinguish the zero-homed domain's NSAPs from all others, which can only be guaranteed with globally unique addresses.

routing

protocol-element §3.3

IDRP allows grouping connected routing domains into Routing Domain Confederations (RDCs) for routing information aggregation. A domain may belong to multiple RDCs simultaneously with no restrictions on nesting, overlap, or disjointness. Each domain is assigned a unique Routing Domain Identifier (RDI) and each RDC a unique RDCI, both syntactically represented as OSI network layer addresses drawn from the same address space.

routing

protocol-element §3.3.1

IDRP's Routing Domain Confederation mechanism enables topological and policy abstraction by replacing a sequence of RDIs in the RD_PATH attribute with a single RDCI. Complementarily, the route aggregation mechanism handles NLRI (reachability) abstraction. Both mechanisms together provide scalable inter-domain routing and are designed to be used together without conflict.

routing

protocol-element §3.3

In IDRP, a Boundary Intermediate System (BIS) participates in inter-domain routing. External neighbors are BISs in different domains sharing a common subnetwork; internal neighbors are BISs in the same domain that may communicate via intra-domain routing without sharing a subnetwork. Routing domains participating in IDRP are not allowed to overlap — a BIS may belong to only one domain.

routing

protocol-element §3.2

IS-IS provides two-level hierarchical routing within a routing domain: Level 1 routers know area topology and forward off-area traffic to Level 2 routers; Level 2 routers form an interconnected backbone subdomain that routes between areas using longest-matching address prefixes. Only Level 2 routers may exchange data or routing information with routers outside their domain.

routing

protocol-element §3.2

NSAP addresses are hierarchically structured into the Initial Domain Part (IDP: AFI + IDI) and Domain Specific Part (DSP: HO-DSP + ID + SEL). For IS-IS routing, the area address is the concatenation of IDP and HO-DSP; the ID field (1–8 octets, fixed per domain) identifies the system; the SEL field (always 1 octet) identifies the transport entity within the system.

routing

security-consideration §3.3

IDRP mandates data integrity and optionally supports data origin authentication for all messages. Each message carries a 16-octet digital signature computed by applying MD-4 (RFC 1320) to the message content. For origin authentication, a BIS may prepend and append out-of-band shared context to the message before signing; this context is not transmitted but is known to the receiver.

routing, security, crypto

security-consideration §3.2

IS-IS carries authentication information in all PDUs using a simple password scheme. Passwords may be associated with each link, each area, and the Level 2 subdomain; a router lacking the appropriate password is prohibited from initializing the link, joining the area, or participating in the Level 2 subdomain. The authentication functions are extensible to support future cryptographic schemes in an upwardly compatible fashion.

routing, security

state-machine §3.2

IS-IS Level 1 routing: a Level 1 IS recognizes whether a destination address is within its area (routes toward the destination using the ID field) or outside (forwards to the nearest Level 2 IS that advertises 'attached' status in its Level 1 routing packets). A Level 1 IS refuses to neighbor with a router whose area addresses do not overlap its own.

routing

state-machine §3.2

IS-IS Level 2 routing: Level 2 ISs distribute area addresses throughout the Level 2 subdomain and compute next-hop forwarding using longest-matching address prefix, preferring internal routes over external routes. A Level 2 IS accepts any other Level 2 IS as a neighbor regardless of area address; links with non-overlapping area addresses are treated as Level 2 only.

routing

wire-format §4.2

GOSIP Version 2 NSAP structure: AFI(1 octet) + IDI(2 octets) + DFI(1 octet) + AA(3 octets) + Rsvd(2 octets) + RD(2 octets) + Area(2 octets) + ID(6 octets) + SEL(1 octet), totaling 20 octets. AFI=47, IDI=0005 identifies the U.S. Government as the DSP authority under ISO 6523-ICD format.

routing