On Wednesday, February 26th, the NEARnet Steering Committee accepted the recommendation of the technical subcommittee by adopting the following policy for the routing of CLNS traffic within NEARnet. It is hoped that this plan will assist OSI interoperability testing between developers and lead to more mature OSI products in the future. Please direct any questions or comments to "nearnet-eng@nic.near.net". John Curran NEARnet Staff --- NEARnet OSI Routing Plan This is an informational document specifying guidelines for the implementation of Open Systems Interconnection (OSI) connectionless network protocol (CLNP) networking within NEARnet. The document describes a plan for coordinating OSI addressing, assigning routing domains to NEARnet members, establishing CLNP routing within NEARnet, and coordinating CLNP routing with external networks. This document does not specify that NEARnet will offer CLNS transport service; requests for CLNS non-production trials will be accepted from members with existing expertise (as demonstrated by a history of the support of CLNS on their own internal networks.) This document is intended for NEARnet members but may be useful to other members of the Internet community. Much of the material herein is based upon the "CICNET OSI ROUTING ARCHITECTURE" by Tom Easterday (CICNet) and Linda Winkler (ANL) and NEARnet is grateful for their assistance. It is hoped that documents such as these will help encourage the growth of OSI services within the Internet. NEARnet OSI Addressing ====================== In OSI, each system is associated with a Network Service Access Point (NSAP) address. NSAP's are analogous to Internet Protocol (IP) addresses in that each system must be assigned a unique address in order to successfully communicate. In IP, the addresses that a given system may be assigned is constrained by the IP network number it is attached to. This allows for abstraction of routing information by other networks. NSAP's are structured in a similar manner which allows abstraction of routing information to occur at many different levels in the network. The document that defines the semantics of an NSAP is ISO 8348/Addendum 2. The basic components of the NSAP is the initial domain part (IDP) and the domain specific part (DSP). The initial domain part identifies the authority that is responsible for both the structure and the uniqueness of the address. In NEARnet, the vast majority of the NSAP's encountered will be within the same initial domain part: 47.0005. This is the portion of the NSAP address space which is assigned to the U.S. Government. This IDP is administered by the General Services Administration (GSA) for the National Institute of Standards and Technology (NIST). U.S. organizations may apply to GSA for their own unique prefix for the domain specific portion of this address space, and such prefixes are known as administrative authority identifiers. NEARnet has been assigned an Administrative Authority (AA) value by the GSA. This AA value identifies a set of NSAP addresses which may be allocated to NEARnet members as needed. The AA assigned to NEARnet is FFFE00 (16) and the addresses follow the GOSIP V2 NSAP format: 47.0005.80.FFFE00.rsvd.RD.Area.ID.SEL where rsvd is two reserved octets of zero RD is a two octet routing domain Area is a two octet area within the RD ID is a six octet system identifier and SEL is a one octet nsap selector. The NEARnet backbone will be assigned one Routing Domain Identifier (RD) out of the NEARnet AA. Each NEARnet member will be assigned one or more RDs from the NEARnet AA. Each member will have the authority to assign Area Identifiers (2 bytes) within its RD to best serve its topology and its users. NEARnet backbone routers will carry only information about members' routing domains, and will not carry information about member area assignments. As a result, each member's local addressing and topology will be transparent to the NEARnet backbone routers. Sites with connections to networks in different AAs, or whose primary path is a network other than NEARnet may want to obtain an RD >From that network's administrative authority. For NEARnet members who are assigned an AA by another authority, the NEARnet backbone routers will carry the minimum amount of information needed to route to that member. In some cases it may be necessary for members to acquire their own Administrative Authority assignment if they desire multiple network connections to provide automatic failover between providers. NEARnet CLNP Routing ==================== Any NEARnet member which participates in CLNS transport will provide an NSAP address for the NEARnet router on their network. The NEARnet router will use Cisco's IGRP to exchange CLNP routing information with a site if the site is using a Cisco router. If it is not, static CLNP routing will be used until the ISO Interdomain Routing Protocol (IDRP) is widely available from router vendors. Routing between AAs will occur where NEARnet peers with other network service providers. Such routing exchanges will involve the minimum information needed to represent the networks served. In the initial case, NEARnet will provide other network providers with a route to NEARnet's AA prefix which will be sufficient to route to all NEARnet provided routing domains. Additional routes would be exchanged as NEARnet members acquire their own AA assignments. Again, IGRP or static routing will be used to facilitate these routing exchanges until IDRP is readily available. Routing within NEARnet will use IGRP. Each NEARnet router will be assigned as NSAP from a single NEARnet backbone routing domain. Member routing domains will be assigned based upon the hub or branch node connected into, which will allow for route aggregation at each hub. This aggregation will reduce the routing workload on the individual routers, and will also allow for future network topologies based upon state or LATA boundaries. It is expected that members may move from branch node to branch node in the future; the goal of allocating routing domains is simply an optimization which allows for route compression for the normal case. NEARnet Routing Domain Requests =============================== Members who require a routing domain assignment for participation in OSI networking should fill out a Routing Domain Assignment request (available via ftp from nic.near.net:/docs/osi-routing-domain-request.txt) and mail the completed request to "nearnet-eng@nic.near.net". From jcurran@nic.near.net Fri Feb 28 14:23:14 1992 Received: from nic.near.net by merit.edu (5.65/1123-1.0) id AA21419; Fri, 28 Feb 92 14:14:23 -0500 Message-Id: <9202281914.AA21419@merit.edu> To: osi-interop@merit.edu Subject: NEARnet OSI Routing Plan Date: Fri, 28 Feb 92 14:14:21 -0500 From: John Curran Status: RO FYI. /John ------- Forwarded Message Received: from nic.near.net by nic.near.net id aa18311; 28 Feb 92 13:12 EST To: nearnet-tech@nic.near.net cc: nearnet-tc@nic.near.net Reply-to: nearnet-eng@nic.near.net Subject: NEARnet OSI Routing Plan Date: Fri, 28 Feb 92 14:11:26 -0500 From: John Curran On Wednesday, February 26th, the NEARnet Steering Committee accepted the recommendation of the technical subcommittee by adopting the following policy for the routing of CLNS traffic within NEARnet. It is hoped that this plan will assist OSI interoperability testing between developers and lead to more mature OSI products in the future. Please direct any questions or comments to "nearnet-eng@nic.near.net". John Curran NEARnet Staff - --- NEARnet OSI Routing Plan This is an informational document specifying guidelines for the implementation of Open Systems Interconnection (OSI) connectionless network protocol (CLNP) networking within NEARnet. The document describes a plan for coordinating OSI addressing, assigning routing domains to NEARnet members, establishing CLNP routing within NEARnet, and coordinating CLNP routing with external networks. This document does not specify that NEARnet will offer CLNS transport service; requests for CLNS non-production trials will be accepted from members with existing expertise (as demonstrated by a history of the support of CLNS on their own internal networks.) This document is intended for NEARnet members but may be useful to other members of the Internet community. Much of the material herein is based upon the "CICNET OSI ROUTING ARCHITECTURE" by Tom Easterday (CICNet) and Linda Winkler (ANL) and NEARnet is grateful for their assistance. It is hoped that documents such as these will help encourage the growth of OSI services within the Internet. NEARnet OSI Addressing ====================== In OSI, each system is associated with a Network Service Access Point (NSAP) address. NSAP's are analogous to Internet Protocol (IP) addresses in that each system must be assigned a unique address in order to successfully communicate. In IP, the addresses that a given system may be assigned is constrained by the IP network number it is attached to. This allows for abstraction of routing information by other networks. NSAP's are structured in a similar manner which allows abstraction of routing information to occur at many different levels in the network. The document that defines the semantics of an NSAP is ISO 8348/Addendum 2. The basic components of the NSAP is the initial domain part (IDP) and the domain specific part (DSP). The initial domain part identifies the authority that is responsible for both the structure and the uniqueness of the address. In NEARnet, the vast majority of the NSAP's encountered will be within the same initial domain part: 47.0005. This is the portion of the NSAP address space which is assigned to the U.S. Government. This IDP is administered by the General Services Administration (GSA) for the National Institute of Standards and Technology (NIST). U.S. organizations may apply to GSA for their own unique prefix for the domain specific portion of this address space, and such prefixes are known as administrative authority identifiers. NEARnet has been assigned an Administrative Authority (AA) value by the GSA. This AA value identifies a set of NSAP addresses which may be allocated to NEARnet members as needed. The AA assigned to NEARnet is FFFE00 (16) and the addresses follow the GOSIP V2 NSAP format: 47.0005.80.FFFE00.rsvd.RD.Area.ID.SEL where rsvd is two reserved octets of zero RD is a two octet routing domain Area is a two octet area within the RD ID is a six octet system identifier and SEL is a one octet nsap selector. The NEARnet backbone will be assigned one Routing Domain Identifier (RD) out of the NEARnet AA. Each NEARnet member will be assigned one or more RDs from the NEARnet AA. Each member will have the authority to assign Area Identifiers (2 bytes) within its RD to best serve its topology and its users. NEARnet backbone routers will carry only information about members' routing domains, and will not carry information about member area assignments. As a result, each member's local addressing and topology will be transparent to the NEARnet backbone routers. Sites with connections to networks in different AAs, or whose primary path is a network other than NEARnet may want to obtain an RD from that network's administrative authority. For NEARnet members who are assigned an AA by another authority, the NEARnet backbone routers will carry the minimum amount of information needed to route to that member. In some cases it may be necessary for members to acquire their own Administrative Authority assignment if they desire multiple network connections to provide automatic failover between providers. NEARnet CLNP Routing ==================== Any NEARnet member which participates in CLNS transport will provide an NSAP address for the NEARnet router on their network. The NEARnet router will use Cisco's IGRP to exchange CLNP routing information with a site if the site is using a Cisco router. If it is not, static CLNP routing will be used until the ISO Interdomain Routing Protocol (IDRP) is widely available from router vendors. Routing between AAs will occur where NEARnet peers with other network service providers. Such routing exchanges will involve the minimum information needed to represent the networks served. In the initial case, NEARnet will provide other network providers with a route to NEARnet's AA prefix which will be sufficient to route to all NEARnet provided routing domains. Additional routes would be exchanged as NEARnet members acquire their own AA assignments. Again, IGRP or static routing will be used to facilitate these routing exchanges until IDRP is readily available. Routing within NEARnet will use IGRP. Each NEARnet router will be assigned as NSAP from a single NEARnet backbone routing domain. Member routing domains will be assigned based upon the hub or branch node connected into, which will allow for route aggregation at each hub. This aggregation will reduce the routing workload on the individual routers, and will also allow for future network topologies based upon state or LATA boundaries. It is expected that members may move from branch node to branch node in the future; the goal of allocating routing domains is simply an optimization which allows for route compression for the normal case. NEARnet Routing Domain Requests =============================== Members who require a routing domain assignment for participation in OSI networking should fill out a Routing Domain Assignment request (available via ftp from nic.near.net:/docs/osi-routing-domain-request.txt) and mail the completed request to "nearnet-eng@nic.near.net". ------- End of Forwarded Message