IETF Page 1 April 30, 1993 System Identifiers for TUBA Internet Draft Assignment of System Identifiers for TUBA/CLNP Hosts David M. Piscitello Bellcore dave@sabre.bellcore.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the Internet Draft abstract listing contained in the IETF Shadow Directories (cd internet-drafts) to learn the current status of this or any other Internet Draft. Introduction This Internet-Draft specifies methods for assigning a 6 octet system identifier portion of the OSI NSAP address formats described in "Guidelines for OSI NSAP Allocation in the Internet" (RFC1237, 1991), in a fashion that ensures that the ID is unique within a routing domain. It also recommends methods for assigning system identifiers having lengths other than 6 octets. The 6 octet system identifiers recommended in this Internet-Draft are assigned from 2 globally administered spaces (IEEE 802 or "Ethernet", and IP numbers, administered by the Internet Assigned Numbers Authority (IANA)). At this time, the primary purpose for assuring uniqueness of system identifiers is to aid in autoconfiguration of NSAP addresses in TUBA/CLNP internets (RFC1347, 1992). The guidelines in this paper also establish an initial framework within which globally unique system identifiers, also called endpoint identifiers, may be assigned. Abstract This document describes conventions whereby the system identifier portion of an RFC1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. The mechanism is IETF Page 2 Internet Draft System Identifiers for TUBA April 30, 1993 extensible and can provide a basis for assigning system identifiers in a globally unique fashion. Acknowledgments Many thanks to Radia Perlman of Digital Equipment and Ross Callon of Wellfleet Communications for their insights and assistance. Thanks also to the Ethernet connector to my MAC, which conveniently and quite inobtrusively fell out, enabling me to get an entire day's worth of work done without email interruptions. 1. Background The general format of OSI network service access point (NSAP) addresses is illustrated in Figure 1. _______________________________________________ |____IDP_____|_______________DSP______________| |__AFI_|_IDI_|_____HO-DSP______|___ID___|_SEL_| IDP Initial Domain Part AFI Authority and Format Identifier IDI Initial Domain Identifier DSP Domain Specific Part HO-DSP High-order DSP ID System Identifier SEL NSAP Selector Figure 1: OSI NSAP Address Structure. The recommended encoding and allocation of NSAP addresses in the Internet is specified in RFC 1237. RFC 1237 makes the following statements regarding the system identifier (ID) field of the NSAPA: 1. the ID field may be from one to eight octets in length 2. the ID must have a single known length in any particular routing domain 3. the ID field must be unique within an area for ESs and level 1 ISs, and unique within the routing domain for level 2 ISs. 4. the ID field is assumed to be flat RFC1237 further indicates that, within a routing domain that conforms to the OSI intradomain routing protocol (ISO 10589, 1992) the lower-order octets of the NSAP should be structured as the ID and SEL fields shown in Figure 1 to take full advantage of intradomain IS-IS routing. (End systems with addresses which do IETF Page 3 April 30, 1993 System Identifiers for TUBA Internet Draft not conform may require additional manual configuration and be subject to inferior routing performance.) Both GOSIP Version 2 (under DFI-80h, see Figure 2a) and ANSI DCC NSAP addressing (Figure 2b) define a common DSP structure in which the system identifier is assumed to be a fixed length of 6 octets. _______________ |<--__IDP_-->_|___________________________________ |AFI_|__IDI___|___________<--_DSP_-->____________| |_47_|__0005__|DFI_|AA_|Rsvd_|_RD_|Area_|ID_|Sel_| octets |_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__| Figure 2 (a): GOSIP Version 2 NSAP structure. ______________ |<--_IDP_-->_|_____________________________________ |AFI_|__IDI__|____________<--_DSP_-->_____________| |_39_|__840__|DFI_|_ORG_|Rsvd_|RD_|Area_|_ID_|Sel_| octets |_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__| IDP Initial Domain Part AFI Authority and Format Identifier IDI Initial Domain Identifier DSP Domain Specific Part DFI DSP Format Identifier ORG Organization Name (numeric form) Rsvd Reserved RD Routing Domain Identifier Area Area Identifier ID System Identifier SEL NSAP Selector Figure 2(b): ANSI NSAP address format for DCC=840 2. Autoconfiguration There are provisions in OSI for the autoconfiguration of area addresses. OSI end systems may learn their area addresses automatically by observing the IS-Hello packets transmitted by routers using the ISO 9542 End Sytem to Intermediate System Routing Protocol. RFC 1237 explains that when the ID portion of the address is assigned using IEEE style 48-bit identifiers, an end system can reconfigure its entire NSAP address automatically without the need for manual intervention. 2.1 Autoconfiguration and 48-bit addresses There is a general misassumption that the 6-octet system identifier must be a 48-bit IEEE assigned (ethernet) address. Generally speaking, autoconfiguration does not rely on the use of a 48-bit ethernet style address; any system identifier that is IETF Page 4 Internet Draft System Identifiers for TUBA April 30, 1993 globally administered and is unique will do. The use of 48-bit/6 octet system identifiers is "convenient...because it is the same length as an 802 address", but more importantly, choice of a single, uniform ID length allows for "efficient packet forwarding", since routers won't have to make on the fly decisions about ID length (see Perlman, 1992, pages 156-157). Still, it is not a requirement that system identifiers be 6 octets to operate the the IS-IS protocol, and IS-IS allows for the use of IDs with lengths from 0 to 8 octets. (Clearly, zero length IDs make for rather uninteresting autoconfiguration opportunities). 3. System Identifiers for TUBA/CLNP Autoconfiguration is a desirable feature for TUBA/CLNP, and is viewed by some as "essential if a network is to scale to a truly large size" (Perlman, 1992). For this purpose, and to accommodate communities who do not wish to use ethernet style addresses, a generalized format that satisfies the following criteria is desired: + the format is compatible with installed end systems complying to RFC 1237 + the format accommodates 6 octet, globally unique system identifiers that do not come from the ethernet address space + the format accommodates globally unique system identifiers having lengths other than 6 octets The format and encoding of a globally unique system identifier that meets these requirements is illustrated in Figure 3: Octet 1 Octet 2 Octet 3 ... Octet LLL-1 Octet LLLL +-----------+-----------+-----------+- ...-+-----------+-----------+ | xxxx TTQQ | xxxx xxxx | xxxx xxxx | | xxxx xxxx | xxxx xxxx | +-----------+-----------+-----------+- ...-+-----------+-----------+ Figure 3. General format of the system identifier 3.1 IEEE 802 Form of System Identifier The format is compatible with globally assigned IEEE 802 addresses. Octet 1 identifies a 2 bit qualifier (QQ) and an optional subtype (TT) whose semantics are associated with the qualifier. If the qualifier QQ equals 10 or 11, there is no subtype (I told you it was optional); the system identifier is interpreted as a 48-bit, globally unique identifier assigned from the IEEE 802 committee (an ethernet address). The remaining bits in octet 1, together with octets 2 and 3 are the vendor code or IETF Page 5 April 30, 1993 System Identifiers for TUBA Internet Draft OUI (organizationally unique identifier), as illustrated in Figure 4. The ID is encoded in IEEE 802 canonical form. Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 +-----------+-----------+-----------+-----------+-----------+-----------+ | VVVV VV01 | VVVV VVVV | VVVV VVVV | SSSS SSSS | SSSS SSSS | SSSS SSSS | +-----------+-----------+-----------+-----------+-----------+-----------+ |------------vendor code -----------|--------station code---------------| Figure 4. IEEE 802 form of system identifier 4. Embedded IP Address as System Identifier If qualifer QQ = 00, the subtype (TT) bits in Figure 3 are relevant. If the subtype (TT) = 00, then the length of the system identifier is 48-bits/6 octets. The remaining nibble in octet 1 is set to zero. Octet 2 is reserved and has a pre- assigned value (see Figure 5). Octets 3 through 6 contain a valid IP address, assigned by IANA. Each octet of the IP address is encoded in hexadecimal, in internet canonical form, i.e., the leftmost bit of the network number first. Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 +-----------+-----------+-----------+-----------+-----------+-----------+ | 0000 0000 | 1010 1010 | aaaa aaaa | bbbb bbbb | cccc cccc | dddd dddd | +-----------+-----------+-----------+-----------+-----------+-----------+ |-len&Type--|--reserved-|---------IP address----------------------------| Figure 5. Embedded IP address as system identifier As an example, the host "eve.bellcore.com = 128.96.90.55" could retain its IP address as a system identifier in a TUBA/CLNP network. The encoded ID is illustrated in Figure 6. Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 +-----------+-----------+-----------+-----------+-----------+-----------+ | 0000 0000 | 1010 1010 | 1000 0000 | 0110 0000 | 0101 1010 | 0011 0111 | +-----------+-----------+-----------+-----------+-----------+-----------+ |-len&Type--|--reserved-|---------IP address----------------------------| Figure 6. Example of IP address encoded as ID H 2 "Other forms of System Identifiers" To allow for the future definition of additional 6-octet system identifiers, the remaining qualifier/subtype values are reserved. IETF Page 6 Internet Draft System Identifiers for TUBA April 30, 1993 It is also possible to identify system identifiers with lengths other than 6 octets. Communities who wish to use 8 octet identifiers (for example, embedded E.164 international numbers for the ISDN ERA) must use a GOSIP/ANSI DSP format that allows for the specification of 2 additional octets in the ID field, perhaps at the expense of the "Rsvd" fields; this document recommends that a separate Domain Format Indicator value be assigned for such purposes; i.e., a DFI value that is interpreted as saying, among other things, "the system identifier encoded in this DSP is 64-bits/8 octets. The resulting ANSI/GOSIP DSP formats under such circumstances are illustrated in Figure 7: ______________ |<--_IDP_-->_|______________________________ |AFI_|__IDI__|____________<--_DSP_-->_______| |_39_|__840__|DFI_|_ORG_|RD_|Area_|_ID_|Sel_| octets |_1__|___2___|_1__|__3__|_2_|__2__|_8__|_1__| Figure 7a: ANSI NSAP address format for DCC=840, DFI=foo _______________ |<--__IDP_-->_|___________________________________ |AFI_|__IDI___|___________<--_DSP_-->____________| |_47_|__0005__|DFI_|AA_|_RD_|Area_|ID_|Sel_| octets |_1__|___2____|_1__|_3_|_2__|_2___|_8_|_1__| IDP Initial Domain Part AFI Authority and Format Identifier IDI Initial Domain Identifier DSP Domain Specific Part DFI DSP Format Identifier AA Administrative Authority RD Routing Domain Identifier Area Area Identifier ID System Identifier SEL NSAP Selector Figure 7b: GOSIP Version 2 NSAP structure, DFI=bar Similar address engineering can be applied for those communities who wish to have shorter system identifiers; have another DFI assigned, and expand the reserved field. 5. Conclusions This proposal should debunk the "if it's 48-bits, it's gotta be an ethernet address" myth. It demonstrates how IP addresses may be encoded within the 48-bit system identifier field in a compatible fashion with IEEE 802 addresses, and offers guidelines for those who wish to use system identifiers other than those enumerated here. IETF Page 7 April 30, 1993 System Identifiers for TUBA Internet Draft 6. References RFC1237. Callon, R., Gardner, E., and Colella, R. "Guidelines for OSI NSAP Allocation in the Internet", June 1991. RFC1347. Callon, R., "TCP/UDP over Big Addresses (TUBA)", May 1992. ISO 10589. ISO, Intradomain routing protocol for use in conjunction with ISO 8473, Protocol for providing the OSI connectionless network service. ISO 9542. ISO, End-system and intermediate-system routing protocol for use in conjunction with ISO 8473, Protocol for providing the OSI connectionless network service. Perlman Perlman, Radia., Interconnections: Bridges and Routers, Addison-Wesley Publishers, Reading, MA. 1992. 7. Author Information David M. Piscitello Bell Communications Research NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 dave@mail.bellcore.com