INTERNET-DRAFT Kim, Yong-Woon draft-qkim-addr-comp-01.txt Park, Jung-Soo July 23, 1999 Koh, Seok-Ju Expires: December 31, 1999 Kang, Shin-Gak Category: Informational Kim, Yong-Jin ETRI/PEC Comparison of the Addressing Schemes of the Internet and OSI Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The OSI service/protocol and Internet TCP/IP suite are typical protocol architectures for data transport in computer communications. A protocol architecture designs its own addressing scheme to distinguish communication objects. The OSI domain has developed an addressing system based on ITU-T Recommendation X.200 | ISO/IEC 7498 OSI Reference Model while the Internet has advertised its own way of addressing. It is necessary to understand them and to analyze the mapping relationship between them so that OSI services and protocols can be adapted over IP-based networks or a transport layer protocol can be developed for both OSI and IP networks. Additionally this memo can serve as a reference in order to produce an address interpretation scheme between SCN (Switched Circuit Network) and IP network. Kim, et. al. [Page 1]
Internet Draft Addressing Comparison July 23, 1999 Table of Contents 1 Introduction .......................................... 3 2 OSI Addressing ........................................ 3 2.1 TSAP (Transport Service Access Point) ................. 7 2.2 Transport Address ..................................... 7 2.3 TSAP address .......................................... 8 2.4 T-Selector (Transport Selector) ....................... 8 2.5 Calling /Called/Responding address .................... 9 2.6 References ............................................ 9 2.7 T-CEPI (Transport Connection EndPoint Identifier) ..... 10 2.8 Relationships among OSI Addressing Terms .............. 11 3 Internet Addressing ................................... 12 3.1 IP Address ............................................ 12 3.2 Port .................................................. 13 3.3 Socket ................................................ 13 4 Comparison of OSI/Internet Addressing ................. 16 4.1 T-CEPI versus Socket .................................. 16 4.2 T-selector versus Port ................................ 16 4.3 TSAP Address versus A pair of IP/Port ................. 17 5 Conclusion ............................................ 17 6 Security Considerations ............................... 18 7 References ............................................ 18 8 Acknowledgements ...................................... 19 9 Authors' Addresses .................................... 19 Kim, et. al. [Page 2]
Internet Draft Addressing Comparison July 23, 1999 1 Introduction A network may have a number of end nodes and network devices, and an end host may deal with multiple transport connections at the same time. In order to exchange user data through the network, the end node should be distinguished from every other node and network devices in the network, and a transport connection should be identified in the node. A communication system, therefore, needs a way to recognize these communication elements: host and connection. Addressing in the communication system means a method of distinguishing specific objects. For example, addressing in the network layer implies a method of distinguishing a specific host computer in the network, which is expressed in terms of the network address called IP address in the Internet. Once datagrams are transmitted by a host identified with an IP address, they are delivered to the destination host along the forwarding path managed by routing protocols. Addressing in the transport layer enables identification of a transport connection by pointing out each endpoint of the connection. The Internet uses a pair of port and IP address for this purpose. Each protocol uses its own addressing system. The OSI network uses its own addressing system based on the OSI Reference Model specified in ITU-T Rec. X.200 | ISO/IEC 7498, while the Internet uses a pair of IP address and port for its addressing system. Two addressing systems may not be proper for the comparison as they are used in different networks. However, it is necessary to understand them and to analyze the mapping relationship between them so that OSI services and protocols can be adapted over IP-based networks or a transport layer protocol can be developed for both OSI and IP networks. Additionally this document can serve as a reference in order to consider the mapping of telephony addresses as endpoints to the IP and OSI address space, which has been studied in ETSI Project TIPHON, and to develop and identify mechanisms that permit interworking between difference addressing schemes such as E.164, X.121, AESA and IP, which has been regarded in GII. Those two schemes of addressing are described in Chapter 2 and 3, and compared in Chapter 4. Then the conclusion is in Chapter 5. 2 OSI Addressing The conceptual diagram of the transport and session layers as shown in Figure 1 may be drawn in order to understand the addressing system in the OSI communication environment. Figure 2 shows an example of Kim, et. al. [Page 3]
Internet Draft Addressing Comparison July 23, 1999 the OSI addressing structure from the data link layer to the session layer. Basic terms are defined below for detail description of the addressing system: - Transport subsystem: An open system is constructed of a set of layers. Each layer in a given open system defines one subsystem, ex., the transport subsystem for the transport layer. Therefore, a transport subsystem is an element in the hierarchical division of an open system, that is, in the transport layer. A transport subsystem interacts directly only with elements in the session and network subsystems of that open system.[1] - Transport entity: A transport entity is an active element within a transport subsystem embodying a set of capabilities defined for the transport layer. Since a transport entity represents communication capabilities of the transport layer, different communication capabilities of the transport layer may be represented by different transport entities ? i.e., there may be several transport entities within a transport subsystem. Two different transport protocols may be represented by two different transport entities.[1] For example, TCP and UDP are two different transport entities in a transport subsystem. The above conceptual definitions can be applied to other protocol layers such as network, session, presentation, and application. Kim, et. al. [Page 4]
Internet Draft Addressing Comparison July 23, 1999 +---------------------------+ / \ | session entity | \ / +---------------------------+ / \ \ / \ \ / \ \ / +---\---------\-----+ / | \ \ | -----( )---------------|-(* * *)---(* * *)-|----- \ | | / | \ +-----|--------/----+ \ | / +-----------+ +-----------------+ / transport \ / \ | entity | | transport entity | \ / \ / +-----------+ +-----------------+ * : T-CEPI ( ) : TSAP +-----+ | | : transport address +-----+ NOTE - a single 1-to-1 association between session entity and transport entity can be incarnated into a set of transport connections through T-CEPIs. Figure 1 - Entities, TSAPs, Transport Address, and Identifiers [2] Kim, et. al. [Page 5]
Internet Draft Addressing Comparison July 23, 1999 +---------+ +---------+ +---------+ / session A \ / session B \ / session C \ | CO | | CO | | CL | \ / \ / \ / +---------+ +---------+ +---------+ | / / | | t2 t3 / t4/ | +--|-------------/---/-+ +--|--+ =======|=(|)==========(/)=(/)=|================|=(|)=|====== +--|-----------/---/---+ +--|--+ | / / T1 | T5 | / / | +--------------+ +---------+ / transport \ / transport \ | CO | | CL | \ / \ / +--------------+ \ +---------+ | | \ | | | \ | +--|----|------------\----+ +--|--+ ===========|=(|)==(|)============(\)=|=========|=(|)=|====== +--|----|----------------\+ +--|--+ | | N1 \ | N2 | | \ | +--------------+ \ +---------+ / network \ / network \ | CO | | CL | \ / / \ / +--------------+ / / +---------+ | | / / | | | / / | +--|----|--+ +----/--/------------|--+ ===========|=(|)==(|)=|======|=(/)(/)============(|)=|====== +--|----|--+ +/--/----------------|--+ | | D1 / / D2 | | | / / | +--------------+ / +---------+ / data link \ / data link \ | CO | | CL | \ / \ / +--------------+ +---------+ T1 : transport address N1 : network address t2 : TSAP address N2 : network address t3 : TSAP address t4 : TSAP address D1 : data link address T5 : transport address D2 : data link address Figure 2 - Example of an addressing structure for layers 2 to 5 [1] Kim, et. al. [Page 6]
Internet Draft Addressing Comparison July 23, 1999 As shown in Figure 1 and 2, several terms are used for the OSI addressing. The definitions and detail descriptions of these terms are mentioned below. 2.1 TSAP (Transport Service Access Point) TSAP is the point at which transport services are provided by a transport entity to a session entity.[2] A transport entity is attached to one or more TSAPs to provide transport services to the session layer as shown in Figure 1. In order to do so the transport entity may use network services from the network layer provided through one or more NSAPs.[1] 2.2 Transport Address A transport address identifies a TSAP or a set of TSAPs that are all located at the boundary between a transport subsystem and a session subsystem.[1,3] A transport address is used to locate a session entity or several session entities that all provide the same functionalities.[1] It seems to be a novel definition. Actually, one-to-one relation is much better than one-to-many relation in an implementation. ITU-T Rec. X.214 | ISO/IEC 8072 also limits the transport address to identification of only one TSAP. According to ISO/IEC 7498-3, it is defined that a session subsystem may be divided into session entities in order to distinguish different session protocols or sets of session protocols. When a session subsystem is very complicated and composed of several session entities, it is important to simplify the complicated system through a proper addressing scheme. A transport address may be used for this purpose. It is required to distinguish between the semantics of a transport address and the syntax used to represent a transport address within a given open system. The semantics of a transport address are conveyed to the peer transport subsystem. The syntax of a transport address is a local matter and different representations may be used in different open systems. Thus the values of corresponding parameters on the sender and the recipient sides must be semantically equivalent, but need not be syntactically identical. A transport address does not only include addressing information pertinent to the transport layer, but also contains addressing information pertinent to the network layer. A transport address is passed as a parameter of transport service primitives through a TSAP.[1] Kim, et. al. [Page 7]
Internet Draft Addressing Comparison July 23, 1999 2.3 TSAP address A TSAP address is a transport address that identifies only a single TSAP.[1] In other words, a TSAP is identified by a TSAP address expressed in terms of the transport address that may point to a TSAP or a bundle of TSAPs. For example, the transport address T1 in Figure 2 enables a session entity to identify three TSAP addresses of T2, T3, and T4 as one bundle. 2.4 T-Selector (Transport Selector) Above the network layer, the scope of addressing is restricted, as the entities to be addressed lie within the open system identified at the network level by use of the network address. It is possible to take advantage of local selectors instead of full addresses and then make them shorter than full addresses. In summary, the information needed to access an application entity is the tuple: Application address = Network address + T-selector + S-selector + P-selector where the network address is carried by network protocols, and T-, S- and P-selectors are carried respectively by transport, session and presentation protocols. Thus the (N)-address is equivalent to the pair "(N-1)-address, (N)-selector". For example, a session address is a pair of transport address and S-selector. It should be noted that an (N)-selector value unambiguously identifies a set of (N)-SAPs which are all in the same (N)-subsystem and that an (N-1) selector value cannot be derived from an (N)-selector value. (N)-selector values are specified locally by each open system for the transport, session and presentation protocols in order to identify session, presentation and application entities respectively. Because (N)-selectors only need to be unambiguous within their respective (N)-subsystems, there is no need for registration authorities.[1] For example, a transport address can be described below: Transport address = Network address + T-selector NOTE - Herein "+" means "a pair of" throughout this document. So the above case means, "the transport address is a pair of network address and T-selector." The abstract syntax of the T-selector is an entirely local issue. The T-selector value is chosen by the local administration in the scope of which is unambiguous within an open system. The local administrator must choose the abstract syntax and encoding technique to be used to represent this value.[1] Kim, et. al. [Page 8]
Internet Draft Addressing Comparison July 23, 1999 According to ITU-T Rec. X.224 | ISO/IEC 8073, there is a protocol field called a transport selector (T-selector) at the variable part of CR-TPDU, which is used as a means for identifying TSAP while establishing the transport connection. However, as the parameter value of the T-selector is defined in terms of an identifier, the T-selector in CR-TPDU may be different from the T-selector given by a session entity. If different T-selector values are used by the service and protocol, a mapping table handling this should be managed internally. When a T-selector is given in the request primitive, it may be returned in the confirmation primitive even though T-selector usages are different. However, as the T-selector is a local matter, a communication system may share a common T-selector value at the session and transport entities. That is, a T-selector value is given in the request and used again in CR-TPDU for the T-selector protocol field. Anyway, this is a syntax problem and a local issue. So it can be solved in various ways. 2.5 Calling /Called/Responding address Following definitions can be described:[1] - Calling transport address: whenever a session entity wishes to establish a transport connection or to issue a connectionless unit of data, it must indicate the transport address of the intended partner and may indicate its own address. That is, the calling transport address is this initiator's transport address which may be referred to as the source transport address; - Called transport address: the partner address is indicated as the called transport address that may be referred to as the destination transport address. This address indicates the transport address of the TSAP or set of TSAPs, which gives access to the desired partner. In order to obtain this information, the calling session entity makes local usage of directory functions before the connection establishment; and - Responding transport address: the responding transport address is a parameter which may appear in a transport service response or confirm primitive issued for the purpose of connection establishment but which is not applicable for connectionless mode. It indicates the transport address at the transport recipient and thus identifies a set of TSAPs at this transport recipient. 2.6 References According to ITU-T Rec. X.224 | ISO/IEC 8073, the reference value is locally selected by the transport entity initiating the CR-TPDU to Kim, et. al. [Page 9]
Internet Draft Addressing Comparison July 23, 1999 identify the requested transport connection. It must be unique within a transport entity. So the initiating transport entity selects a local source reference value and sets as "0" the destination reference value initially for the CR-TPDU. The responding transport entity selects its local source reference that will become the destination reference at the sender side and responds with the CC-TPDU. Then these two transport entities can know the source and destination reference values on their own side. 2.7 T-CEPI (Transport Connection EndPoint Identifier) Multiple transport connections can be established at a single TSAP and distinguished by T-CEPI. T-CEPI is an identifier of a transport connection endpoint that is used to identify the corresponding transport connection at a TSAP. A session entity may create a transport connection with another session entity by using a connection establishment transport service. When a session entity establishes a transport connection with another session entity, each session entity is given a T-CEPI by its supporting transport entity. The session entity can then distinguish the new connection from all other transport connections accessible at the TSAP it is using. The T-CEPI is unique within the scope of the session entity that will use the transport connection. The structure of T-CEPI is specified as follows:[2] T-CEPI = TSAP address + T-CEPI-suffix (transport connection endpoint suffix) where the suffix should be unique within the scope of the TSAP. In the implementation perspective, a system function call for connection establishment corresponds to an invocation of the transport connection request service. A T-CEPI can be returned for for the system call from the transport subsystem wherein its suffix value will be allocated like the reference. Then the session entity can distinguish many transport connections with respect to one TSAP through such T-CEPI. The T-CEPI is a connection endpoint identifier from the point of view of the session entity. A separate connection identifier is necessary for the transport subsystem itself, which has to be mapped with the T-CEPI. The reference value in Chapter 2.6 takes this very role. Therefore, T-CEPI and reference are conceptually identical, but Kim, et. al. [Page 10]
Internet Draft Addressing Comparison July 23, 1999 T-CEPI-suffix and reference can be syntactically identical. This is also a local issue. 2.8 Relationships among OSI Addressing Terms Based on the above description, the OSI addressing information may be described briefly in terms of the following expressions: Transport Address = Network Address + T-selector TSAP address = Transport Address of a TSAP = Network Address + T-selector of a TSAP Calling Address = Transport Address of a calling TSAP = Calling TSAP address = Network Address + Calling T-selector T-CEPI = TSAP address + T-CEPI-suffix T-CEPI-suffix = Reference According to ITU-T Rec. X.200 | ISO/IEC 7498-1, the transport address enables a TSAP or a set of TSAPs to be recognized as one, and the T-selector distinguishes a single TSAP or a bundle of TSAPs. In the case of 1-to-1 relationship, therefore, all TSAP addresses of an open system use the same NSAP address and separate T-selectors for identification of each TSAP where the NSAP address is unique globally in the open network and the T-selectors are unique locally and allocated by the session entity. Since the calling address of the request primitive is defined to be the calling TSAP address in ITU-T Rec. X.214 | ISO/IEC 8072, the calling address is limited to identification of only one TSAP even though it can point to a set of TSAPs. Therefore, the calling T-selector is a local parameter enabling identification of a single TSAP. Consequently, the calling session entity produces the calling TSAP address along with its own network address by allocating an arbitrary value for the calling T-selector as well as the called TSAP address with the destination network address by allocating a well-known destination T-selector value. Wherein the calling session entity may make local usage of directory functions to get the called TSAP address. Then the session entity may issue a request service using these two addresses and get a T-CEPI from the transport subsystem. If the session entity issues multiple connection request services using the same two addresses, it gets different T-CEPIs that enable resulting transport connections to be distinguished. The transport entity may use the same T-selector for CR-TPDU as one given by the session entity, or use an identifier of the given T-selector. Or it can use the TSAP address, not only T-selector. Kim, et. al. [Page 11]
Internet Draft Addressing Comparison July 23, 1999 A different way may be employed according to the OSI implementation. ITU-T X.224 | ISO/IEC 8073 defines an identifier of the given T-selector for CR-TPDU. The T-CEPI is referred to from the point of view of the session entity, while the reference is referred to from the point of view of the transport entity. But they are identical semantically and associated with each other even though they are different syntactically. When the transport entity opens a transport connection, it assigns an arbitrary value to the source reference and "0" to the destination reference. The source reference value can be returned along with the TSAP address to the session entity in terms of the T-CEPI. As a result, a CR-TPDU is transmitted to a receiving transport entity. The destination reference comes into the source reference and the source reference does into the destination reference at the peer side. The receiving transport entity also allocates an arbitrary value for its source reference. But the receiver can know its destination reference from the source reference of the CR-TPDU where the two reference values must be identical. It responds with a CC-TPDU that is transmitted to the initiating transport entity. Then both the sender and the peer receiver know their source and destination reference values and are able to identify connections through the reference values. 3 Internet Addressing The Internet addressing is much simpler than the OSI addressing. It can be described in terms of IP address for the network layer addressing, port for the transport layer addressing, and socket for identification of a connection endpoint in the local system. 3.1 IP Address It is a 32-bit address used to identify a host computer connected to the Internet. This information is indicated in terms of the source IP and destination IP addresses at the header of IP datagram and is used throughout networks when delivering from the source to the final destination host. The address is normally written as four decimal numbers, one for each byte of the address. Instead of using a flat address space such as 1, 2, 3, and so on, the IP address space has been structured into address classes: A, B, C, D and E. The easiest way to differentiate between the different classes of addresses is to look at the first number of a dotted-decimal address.[6] Kim, et. al. [Page 12]
Internet Draft Addressing Comparison July 23, 1999 3.2 Port According to RFC 793, the TCP provides a set of addresses or ports within each host in order to allow for many processes within a single host to use TCP communication facilities simultaneously. TCP and UDP identify applications using 16-bit port numbers. The binding of ports to processes is handled independently by each host. However, it proves useful to attach frequently used processes to fixed ports which are made known to the public. These services can then be accessed through the known port numbers.[7] Servers are normally known by their well-known port number: TCP port 21 for FTP, TCP port 23 for TELNET, UDP port 69 for TFTP, etc. Those services that can be provided by any implementation of TCP/IP have well-known port numbers between 1 and 1023. The well-known ports are managed by the ICANN.[6] A client usually doesn't care what port number it uses on its end. All it needs to be certain of is that whatever port number it uses be unique on its host. Client port numbers are called ephemeral ports (i.e., short lived). This is because a client typically exists only as long as the user running the client needs its service, while servers typically run as long as the host is up.[6] That is, many transport connections can be established simultaneously between multiple clients and a single server while different ports are used by the clients and one port is used by the server. 3.3 Socket Concatenated with the network and host addresses from the Internet communication layer, this forms a socket, that is, a pair of IP address and port number in the Internet. When many processes use TCP communication facilities simultaneously, a pair of sockets identifying its two endpoints uniquely specifies each connection.[7] In other words, four-tuple of client IP address, client port number, server IP address, and server port number provide identification of TCP connections. A socket may be concurrently used in multiple connections. However, as the name of socket is used as one of APIs in the BSD socket interface as well, developers may be easily confused as to the definition of socket. Conclusion is that two terms are different from each other. The socket system function as an API provides a Unix file descriptor which application implementers can use in their process to do reads from and writes in a TCP connection. In other words, if the socket system function is executed, the Unix file descriptor is passed over as a return value by which the API socket is identified in a local Kim, et. al. [Page 13]
Internet Draft Addressing Comparison July 23, 1999 application. But this socket descriptor is not the TCP socket at this point of time since it is not yet bound to the IP address and port number. NOTE - Herein, the API socket is something that is referred to in the BSD Unix Socket Interface, meaning that "An API socket is an instance or incarnation of the TCP socket." Thus it may be used by a different name such as WinSock or not socket, in other API specifications. The bind system function as an API makes the Unix kernel know which IP address and port number the API socket uses. That is, the pair of IP address and port number are bound to the API socket. At this point of time, the API socket is associated with the TCP socket. Using the accept and listen system functions, it is possible to produce a different API socket with respect to the same IP address and port number, and subsequently, to differentiate each API socket by obtaining different socket file descriptors. Wherein the listen command tells the kernel that this socket should wait for incoming connection requests in which the backlog parameter specifies the number of simultaneous connections and connection requests that may be queued. The accept command gets a socket descriptor for an incoming connection in which the listening socket is identified by the file descriptor. That is, one TCP socket can be associated with many API sockets with different socket descriptors. TCP defines that a TCP connection is fully specified by the pair of sockets and a local TCP socket may participate in many connections to different foreign TCP sockets. If two end hosts establish many connections using a single TCP socket at each side, many API sockets will associate each TCP socket. But in this case, it is impossible to distinguish the connections. Because the socket descriptors are used locally and not exchanged, and only the TCP socket address is sent to the peer side. Therefore, there should be an addressing rule that one TCP socket must be associated with only one API socket at the client side and one TCP socket can be related with multiple API sockets at the server side. That is, the API socket of the client is connected only by 1:1 relationship with an ephemeral port number and its IP address, while many API sockets of the server are connected by N:1 relationship with a pair of IP address and port. Then each connection can be easily distinguished by a pair of TCP sockets of the two ends. However, such addressing scheme may not be a proper way from the point of view of the protocol layer. It may be a conceptually understandable way and its implementation may be feasible well. But Kim, et. al. [Page 14]
Internet Draft Addressing Comparison July 23, 1999 it is deemed to be improper that the IP address of the network layer has to be reviewed in order to identify connections of the transport layer, from the point of view of the protocol layer structure in which each layer should not be dependent on other layers. +----------+ 21 2000 +--------+ | |------------------------| | | | 21 2001 | host A | | |------------------------| | | | +--------+ | | | server S | 21 2000 +--------+ | |------------------------| | | | 21 2001 | | | |------------------------| host B | | | 21 2002 | | | |------------------------| | +----------+ +--------+ Figure 3 - An example of TCP connections For example, assuming that Host A and B establish TCP connections simultaneously with Server S for the FTP service, Host A can use port number 2000 and 2001, as well as Host B can use port number 2000, 2001, and 2002 coincidentally. Host A can learn to which API socket each segment has to be delivered since the destination port numbers are 2000 and 2001 although the source port number is the same, 21, in view of the TCP segments which arrives at Host A from Server S. This is the same for B. But, from the point of view of Server S, the destination port of all arriving TCP segments is number 21. The source ports of arriving segments from two hosts A and B are number 2000 and 2001 identically herein except for number 2002 from Host B. Then Server S cannot learn to which API socket each segment has to be delivered. Therefore, the IP address has to be referred to in order to find out to which API socket of Server S each segment belongs. This is the reason why the addressing information of the network layer has to be referred to for the transport layer addressing. Consequently, it may be described that the TCP/IP protocol structure has the transport layer protocol such as TCP and UDP as well as the network layer protocol such as IP from the conceptual point of view. However, it may be illustrated that the transport layer and network layer protocols are combined with each other like a layer for their operation from the functional or implementation point of view. Kim, et. al. [Page 15]
Internet Draft Addressing Comparison July 23, 1999 4 Comparison of OSI/Internet Addressing All the above discussions can be summarized into the following comparison table: Table 1 - A Comparison table of OSI/Internet Addressing +----------------------+-----------------------+ | OSI Addressing | Internet Addressing | +----------------------+-----------------------+ | TSAP address | IP + port | | T-selector | port | | T-CEPI (Reference) | socket | +----------------------+-----------------------+ 4.1 T-CEPI versus Socket In order to distinguish transport connections, the T-CEPI and the reference are defined respectively in view of the OSI transport service and protocol, and both produced by the transport entity. Thus, these two parameters are identical semantically but different syntactically because the T-CEPI consists of TSAP address and transport connection endpoint suffix and the reference is just an identifying value like the suffix. Since there may be many T-CEPIs in one TSAP that can be identified by T-selector, there can exist as many transport connections as the number of T-CEPIs. In the Internet, the client and server identify transport connections through the API socket. The client has as many API sockets as the number of connections and each API socket is bound to a different TCP socket which consists of a different port and a common IP address. The server also has as many API sockets as the number of connections, but each API socket is bound to one TCP socket. Therefore, the T-CEPI and the API socket providing a transport connection endpoint show the most agreeable relationship. And yet, there is a difference that the reference value which may be directly mapped from the T-CEPI, enters into the protocol header as the source and destination references, whereas the socket descriptor does not enter into the protocol header. 4.2 T-selector versus Port The OSI model defines a TSAP as an access point providing the service of the transport layer. Since a TSAP address consists of the network address and T-selector, this T-selector points directly to the TSAP. Kim, et. al. [Page 16]
Internet Draft Addressing Comparison July 23, 1999 Many TSAPs based on a common network address can be open and so many T-selectors will be assigned to identify those TSAPs. Similarly, the Internet defines a port as an access point providing the transport layer service. The application layer and transport layers are associated through the port. A single TSAP may have multiple connection endpoints and a single port also may be associated with multiple connection endpoints called API sockets. Therefore, the TSAP and port can be said to have the mapping relationship conceptually. However, since the TSAP address is composed of two composite elements of NSAP address and T-selector, it is deemed that the T-selector coincides very much with the port. Instead, the TSAP may correspond very well to a pair of IP address and port. According to the way to make this relationship, the connection endpoint suffix in Chapter 2.7 can be matched to the socket file descriptor. This confusion occurs from the addressing syntax that may be designed by its own way in an implementation. Thus the semantic addressing relationship should be focused. It is deemed that the mutual mapping relationship is proper since many connections can be produced in one TSAP where they are identified in terms of T-CEPI, and many connections can be produced in one port where they are identified in terms of the API socket. 4.3 TSAP Address versus A pair of IP/Port As described in Chapter 4.2, as the TSAP address is composed of the network address and T-selector, a pair of IP and port may be mapped properly with the TSAP address from the syntactic and semantic points of view. 5 Conclusion The OSI and Internet have the same purpose of transmitting user data through the computer network but different structures of the communication protocols. For example, the protocol structure is divided into seven layers based on the OSI reference model, whereas in the Internet it is divided into five layers in such a way that the application layer is right on top of the transport layer. The roles corresponding to the remaining two layers of the OSI model are to be processed at the application layer in the Internet. Therefore, it may not be desirable to compare two communication systems in the one-to-one way as they have different protocol Kim, et. al. [Page 17]
Internet Draft Addressing Comparison July 23, 1999 structures. However, since it is not easy to encounter the OSI addressing structure in the actual communication environment and it is difficult to understand with abstract illustration, the OSI addressing system is to be understood through the Internet addressing system which has been simple-structured and easily used. Also, the comparison of addressing is deemed to be useful since both addressing systems have to be understood in adaptation of OSI services and protocols for the Internet. Accordingly, the OSI and Internet addressing systems are reviewed, and each addressing information is compared to and mapped with each other. As a result, the TSAP address given as a calling, called, or responding address can be mapped in terms of a pair of the IP address and port number in the Internet. The T-selector which is a composite element of the TSAP address can be mapped in terms of Port, and the T-CEPI which is used for identification of connections can be mapped in terms of the socket descriptor in the Internet. 6 Security Considerations This type of non-protocol document does not directly effect the security of the Internet, OSI network, or other networks. 7 References [1] ISO/IEC TR 10730: 1993, Information technology - Open Systems Interconnection - Tutorial on Naming and Addressing [2] ITU-T Recommendation X.200 (1994) | ISO/IEC 7498-1: 1994, Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model [3] ITU-T Recommendation X.214 (1995) | ISO/IEC 8072: 1996, Information technology - Open Systems Interconnection - Transport Service Definition [4] ITU-T Recommendation X.224 (1995) | ISO/IEC 8073: 1997, Information technology - Open Systems Interconnection - Protocol For Providing The Connection-Mode Transport Service [5] Uyless Black, "OSI - A Model for Computer Communication Standards", pp.267, Prentice-Hall, Inc. [6] W. Richard Stevens, "TCP/IP Illustrated, Volume 1 - The Protocols", Addison-Wesley Publishing Co. [7] Jon Postel, "Transmission Control Protocol", RFC 793, September 1981 Kim, et. al. [Page 18]
Internet Draft Addressing Comparison July 23, 1999 8 Acknowledgements Many people have been joined in developing the ECTP standardization project and made comments and suggestions contributing to ECTP. We would like to thank Daeyoung Kim, Hyun-Kook Kahng, Wolfgang Fritsche, Keith Knightson, Jim Long, Alan Chambers, Juyoung Park, Inyong Hwang, Jin-Ho Hahm, and Gwangsu Kim. This document is one of the results of the project. 9 Authors' Addresses Kim, Yong-Woon ETRI/Protocol Engineering Center 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, Republic of Korea Phone: +82 42 860 6557 Fax: +82 42 861 5404 E-mail: qkim@pec.etri.re.kr Park, Jung-Soo ETRI/Protocol Engineering Center 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, Republic of Korea Phone: +82 42 860 6514 Fax: +82 42 861 5404 E-mail: jspark@pec.etri.re.kr Koh, Seok-Ju ETRI/Protocol Engineering Center 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, Republic of Korea Phone: +82 42 860 6218 Fax: +82 42 861 5404 E-mail: sjkoh@pec.etri.re.kr Kang, Shin-Gak ETRI/Protocol Engineering Center 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, Republic of Korea Phone: +82 42 860 6117 Fax: +82 42 861 5404 E-mail: sgkang@pec.etri.re.kr Kim, Yong-Jin ETRI/Protocol Engineering Center 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, Republic of Korea Phone: +82 42 860 6564 Fax: +82 42 861 5404 E-mail: yjkim@pec.etri.re.kr Kim, et. al. [Page 19]