Internet Engineering Task Force R. G. Cole and D. Shur INTERNET-DRAFT AT&T Bell Laboratories Expires August 17, 1995 February 17, 1995 IP over ATM: A Framework Document 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 lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 1 Abstract The discussions of the IP over ATM working group over the last several years are summarized. The summary is provided in the form of a framework which categorizes the various ATM subnet models and End-to-End models identified and deemed of primary interest by the IP over ATM working group. The intent of this framework was, and still is, to help partition the efforts of the working group in order to focus on smaller, more manageable aspects of IP over ATM. This is necessary due to the number of ATM sub-networks and End-to-End types being discussed. A second goal of this document is to serve as an introduction to and overview of the area of IP and ATM interworking. In summary, it is hoped that this document, in classifying the sub-network and end-to-end models, has helped (and will continue to help) in focusing the IP over ATM working group's direction. The subnet models identified in this memo are: INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 o an SVC-based LAN ATM (LATM) subnet, and o a PVC-based WAN ATM (WATM) subnet. The end-to-end models identified in this memo are: o the Classical IP model, o Ohta's "Conventional" model, o the SVC-based WATM (ROLC) model, o the Integrated Model and o the Peer Model. 2 Introduction The IP over ATM Working Group of the Internet Engineering Task Force (IETF) is chartered to develop standards for routing and forwarding IP packets over ATM sub-networks. There are several difficulties with this charter, as evidenced by the discussions of this group over the last several years. Firstly, the work activity of the group has depended on a technology (asynchronous transfer mode (ATM)) undergoing ongoing development and definition. Secondly, the flexibility of ATM, allows for and in fact encourages the technology to be used in different network/subnetwork arrangements, e.g., a LAN, a WAN, an Internet, etc. Therefore, much of the discussions of the IP over ATM working group have centered around not only how to carry IP traffic over ATM subnetworks, but what is the appropriate view of ATM in the context of IP internetworking. This document attempts to highlight some of these discussions and tries to categorize the various ATM subnet architectures and end-to-end architectures that have been proposed. We first discuss the types of ATM subnets, and then the end-to-end models to be addressed. An appropriately chosen classification/ taxonomy of the various ATM subnet and end-to-end models enables the issues pertaining to particular models to be worked independently. This allows progress to be made in defining IP routing over some ATM subnet types and simpler end-to-end models, without having to resolve fundamental architectural issues in other more complex or vaguely defined models, e.g., peer end-to-end models. Furthermore, the classifying of the subnet and end-to-end models and the enumeration of the associated issues should help in focusing the IP over ATM working group's future direction. Cole, Shur Expires August 17, 1995 [Page 2] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 The remainder of this memorandum is organized as follows: o Section 3 defines several terms relating to networking and internetworking, o Section 4 discusses the parameters for a taxonomy of the different ATM subnet and end-to-end networking models to be defined, o Section 5 discusses/identifies the various subnet models proposed to date by the IP over ATM working group, o Section 6 identifies several prominent end-to-end networking configurations, o Section 7 addresses the relationship between the documents developed in the IP over ATM working group and the various models discussed, and o Section 8 contains conclusions. 3 Definitions and Terminology We define several terms: A Host or End System (ES) delivers/receives IP packets to/from other systems, but does not relay IP packets. A Router or Intermediate System (IS) delivers/receives IP packets to/from other systems, and relays IP Packets among systems. A router may route packets to hosts within its own area and to other routers when the destination is within another area. A Subnet is a connected communication network consisting of a single networking technology in which the hosts connected to the subnet share a common IP level 3 network address. Subnets are further categorized into broadcast and non-broadcast multiple access subnetworks. A Broadcast (Multicast) Subnet supports an arbitrary number of hosts and routers and additionally is capable of transmitting a single IP packet to all (a subset) of these systems. A Non-Broadcast Multiple Access (NBMA) Subnet supports an arbitrary number of hosts and routers but does not support a convenient multi-destination connectionless transmission facility, as does a Cole, Shur Expires August 17, 1995 [Page 3] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 Figure 1: A Single Hop configuration between Subnet End Systems (Sub-ES) attached to the same subnet broadcast subnetwork. An End-to-End path consists of two hosts which can communicate with one another over an arbitrary number of routers and subnets. From the perspective of the subnet, in many cases there is no difference between the hosts and routers. Therefore, we will define a Subnet End System (Sub-ES) as a network level entity connected to the subnet, either a host or router. Figure 1 shows two Sub End Systems connected over a single subnet. An IP-level (or L3 level) end-to-end path can be considered as a concatenation of multiple IP-level (or L3) single hop paths. A model of a subnet describes the key characteristics and operational features of the subnet technology used in performing the functions required of an IP subnet. An end-to-end model describes the key aspects, structure and operational features required to provide connectivity among a given set of Sub-End-Systems, possibly located on different sub-networks. Cole, Shur Expires August 17, 1995 [Page 4] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 4 ATM Aspects Affecting Subnet and End-to-End Models 4.1 ATM Parameters Defining Subnet Models In general, each subnet technology may be characterized in terms of many parameters. In the previous section, we have defined two subnet types, i.e. a broadcast and a general topology, or NBMA, subnet. It is possible to specify additional subnet types beyond these broad categories. In this section we present the major parameters/attributes for a taxonomy of the various ATM subnet models discussed in the remainder of this document. The parameters/attributes chosen correspond to those aspects of ATM networks that, when overlaid with IP, and in order to provide standard IP services, require interworking functionality to be provided or particular ATM services to be selected. There are some attributes which play an important role in network models in general (e.g., geographical dispersion, the number of nodes, the number of routers present, etc.) that will not be explicitly highlighted in the taxonomy below since they are not specific to ATM. However, as will be seen in the following sections, the latter attributes do influence the both subnet and end-to-end models. The ATM-specific attributes considered are: o The different types of services provided by the ATM Adaptation Layers (AAL). These specify whether a connection oriented or a connectionless service is provided, the Quality-of-Service, the connection-mode, etc. The models discussed within this document assume connection-oriented, best effort services over AAL Type 5. o The type of virtual circuits used, i.e., PVCs versus SVCs. The PVC environment requires the use of either static tables for ATM-to-IP address mapping or the use of inverse ARP, while the SVC environment requires ARP functionality to be provided. o The type of support for multicast services. If point-to-point services only are available, then a server for IP multicast is required. If point-to-multipoint services are available, then IP multicast can be supported via meshes of point-to-multipoint connections (although use of a server may be necessary due to limits on the number of multipoint VCs able to be supported). o The presence of logical link identifiers (VPI/VCIs) and the various information element (IE) encodings within the ATM SVC signaling specification, i.e., the ATM Forum UNI version 3.1. This allows a VC originator to specify a range of "layer" entities as the destination "AAL User". The AAL specifications Cole, Shur Expires August 17, 1995 [Page 5] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 do not prohibit any particular "layer X" from attaching directly to a local AAL service. Taken together these points imply a range of methods for encapsulation of upper layer protocols over ATM. For example, while LLC/SNAP encapsulation is one approach (the default), it is also possible to bind virtual circuits to higher level entities in the TCP/IP protocol stack. Some examples of the latter are single VC per protocol binding, TULIP, and TUNIC, discussed further in Appendix A. o The number and type of ATM administrative domains/networks, and type of addressing used within an administrative domain/network. In particular, in the single domain/network case, all attached systems may be safely assumed to be using a single common addressing format, while in the multiple domain case, attached stations may not all be using the same common format, with corresponding implications on address resolution. (See Appendix A for a discussion of some of the issues that arise when multiple ATM address formats are used in the same logical IP subnet (LIS).) Also security/authentication is much more of a concern in the multiple domain case. 4.2 Aspects of ATM influencing End-to-end Models The above discussion implies that within an ATM-based subnet architected along traditional lines, significant questions/issues arise. There are also aspects which are stimulating or reviving the development of alternative end-to-end models that differ from the traditional or "Classical IP" model. Two such aspects are: o The assumption of widespread deployment of ATM within both premises-based LANs and wide-area networks, and o The definition of interfaces, signaling and routing protocols among private ATM networks. The ROLC model (not necessarily specific to ATM) would be particularly appropriate to the case of ubiquitous ATM deployment. It preserves routing control in the IP domain, but permits "short-cut" transport in the ATM domain. In an environment with ATM-level routing among private ATM-based networks, Peer Models allow the IP and ATM routing protocols to interact as peers. The "integrated" model allows IP-level routing protocols to obtain and utilize information pertaining to ATM-level routing. These end-to-end models are discussed in more detail in section 6. Cole, Shur Expires August 17, 1995 [Page 6] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 5 Classification of ATM Subnets Several ATM subnets have been discussed by the IP over ATM working group. These range from the (wide-area) Broadband-Integrated Services Digital Network (B-ISDN) subnet originally proposed and being defined by inter-exchange carriers to Local ATM (LATM) subnets, currently being defined by computer and LAN networking vendors. Furthermore, other subnets are defined over ATM as overlay subnets, e.g. Frame Relay over ATM, and 802.3 and 802.5 LANs over ATM, the latter being developed through the LAN emulation activities in the ATM Forum. In this document, we identify and discuss two ATM subnets: an SVC-based LAN-ATM (LATM) subnet, and a PVC-based WAN-ATM (WATM) subnet. 5.1 The SVC-based LATM Subnet Model The SVC-based LAN-ATM (LATM) subnet is characterized as having a large number of hosts, e.g., up to at most a few thousand (but typically fewer). The main characteristics of and assumptions underlying this subnet are listed below: o Hosts o are directly connected, o share a common IP-level (or L3) network prefix, o support switched virtual connections (SVCs), o are part of a single administrative group, and security is not an issue. o The subnet supports an efficient mechanism for address resolution, o The ATM network is capable of setting up connections between any pair of hosts. o Consistent with the standard IP routing algorithm RFC--1009 [3] connectivity to the "outside" world is achieved only through a router, which may provide firewall functionality if so desired o Billing for virtual circuit holding time, or any other usage based measure is assumed to be not an issue. Cole, Shur Expires August 17, 1995 [Page 7] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 For hosts to forward packets over this subnet, many of the mechanisms for forwarding IP packets over ethernet subnets apply and are presented in RFC--1577 [11]. Some of the issues that need to be addressed for this model are: o The definition of an address resolution server. (Many internal architectures are possible ranging from a broadcast capability to the existence of an ARP server. RFC--1577 [11] utilizes the ARP server option, and also specifies administrative procedures. o Defining the maximum MTU size, (This had been the subject considerable debate over the Internet in the spring of 1993. This issue is addressed in RFC--1626 [2].) o Methods of encapsulation and multiplexing, (This was actually the first issue addressed by the group. The group struggled for a year between the LLC/SNAP encapsulation, supported over the majority of subnet types, and the NLPID encapsulation, to ease frame relay to ATM interworking. The LLC/SNAP, and a null encapsulation, were decided upon and are discussed in RFC--1483 [8].) o Reliability of the ARP server mechanism defined in RFC--1577 [11], o Management and signalling of SVCs, such as -- Defining SVC optimization techniques (e.g., time-out mechanisms), and -- Support for IP multicasting, and -- Special purpose SVCs for control/routing and high bandwidth data transfers. Much effort has gone into defining the interface between the Sub-ESs and the LATM, e.g., what VPI/VCIs to be used to access the ARP server, ATM ARP message formats RFC--1577 [11], the method of encapsulation RFC--1483 [8], the maximum MTU sizes RFC--1626 [2], signalling capabilities RFC--1755 [13], etc. However, other work items have consisted of internal architectural issues such as the architectures for ARP multicast services. As already mentioned, several of these issues have been substantially resolved. RFC--1577 [11] defines an ARP server architecture for the SVC-capable LATM model. RFC--1483 [8] defines two methods of multiprotocol encapsulation, a default encapsulation based on LLC/SNAP and another based upon a null encapsulation (supporting a Cole, Shur Expires August 17, 1995 [Page 8] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 single, higher level protocol per ATM VCI). RFC--1626 [2] defines the use of the MTU discovery protocol RFC--1191 [12] for ATM subnetworks. RFC--1755 [13] describes an implementation agreement for routers signaling the ATM subnet to establish SVCs initially based upon the ATM Forum's UNI version 3.0 specification [14] and eventually to be based upon the ATM Forum's UNI version 3.1 and later specifications. Topics addressed in RFC--1755 [13] include (but are not limited to) VC management procedures, e.g., when to time-out SVCs, QOS parameters, service classes, explicit setup message formats for various encapsulation methods, Sub-ES to Sub-ES negotiations, etc. In the summer of 1994, work began on the issue of supporting IP multicasting over the SVC LATM model. The proposal for IP multicasting is found in IPMC [1]. In order to support IP multicasting the ATM subnet must either support point-to-multipoint SVCs, or multicast servers, or both. Outstanding issues, not yet fully discussed, include security over ATM SVC subnets (which would likely require the existence of a user information element used to convey security and authentication information), support for ATM QOS (although this should likely be deferred until the meaning of the Flow ID in IPv6 is defined), and the reliability of the ARP-server architecture. 5.2 The PVC-based WATM Subnet Model The PVC-based WATM is a NBMA subnet which is further characterized as having a moderate number of hosts, e.g., up to at most a few tens or hundreds, which: o are all directly connected, o share a common IP-level (or L3) network prefix, o support permanent virtual connections (PVCs), o do not have to support an efficient broadcast/multicast/connectionless server for address resolution, and o may or may not be part of a single administrative group (however, even if not part of the same administrative group, security is not an issue due to the permanent nature of the virtual connections). For hosts to forward packets over this subnet, many of the mechanisms defined for forwarding IP packets over Frame Relay subnets apply, see RFC--1490 [6]. Specific issues are: Cole, Shur Expires August 17, 1995 [Page 9] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 o Defining the details for an Inv-ARP like address resolution, (Strictly, Inv-ARP is defined for general PVC-based NBMA subnets, see RFC--1293 [5] and RFC--1577 [11].) o Methods of encapsulation and multiplexing, (This issue is addressed in RFC--1483 [8].) o Defining the maximum MTU size, (This issue is addressed in RFC--1626 [2].) and o Support for IP multicasting. The majority of the issues (except for multicasting) have been addressed by the working group. 6 End-to-End Networking Configurations Several end-to-end ATM configurations have been proposed, most constructed by cascading gateways and different ATM subnet models. Other more radical models have been proposed which replace the traditional IP subnet architecture by an ATM Internet model. We categorize these different models in terms of whether the ATM network and IP-level (or L3) routers are considered as peers, i.e. they exchange routing information, or not, i.e. the IP-level (or L3) routers treat the ATM network as a lower-level subnet. We will refer to these as Peer Models and Subnet Models, respectively, and discuss each separately below. Clearly the Subnet Models follow the traditional IP networking architectures, whereas the Peer Models propose a new way of internetworking. Due to this, the consensus of the group was that the problems with the end-to-end peer models were much harder than any of the other models, and had more unresolved technical issues. While encouraging interested individuals/companies to research this area, it was not the priority of the IP over ATM working group to address these difficulties. More recently, discussions of peer models have been revived in the ATM Forum's Network Layer Multiprotocol sub-working group (see below). We now describe End-to-End models starting with the Classical IP model, followed by the remaining models ordered according to the degree of departure from the classical IP architecture. Cole, Shur Expires August 17, 1995 [Page 10] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 Figure 2: The Classical IP model as a concatenation of three separate ATM subnets; two SVC LATM subnets and a single PVC WATM subnet. 6.1 The Classical IP Model The Classical IP Model was suggested at the Spring 1993 IETF meeting RFC--1577 [11] and retains the classical IP subnet architecture. This model simply consists of cascading instances of the two subnet models discussed in the previous section with IP-level (or L3) routers. A example realization of this model consists of a concatenation of two (simplified) LATMs and a PVC-based WATM subnet. This is shown in Figure 2. Once the details of specifying routing and forwarding IP packets over the component subnets are complete, routing IP packets over this Classical IP model is straight forward. The LATMs are simplified in that they: o support a single subnetwork point of attachment (SNPA) address format (four allowed address formats are specified in UNI 3.0 [14], o support a single default MTU size, and o support a default LLC/SNAP encapsulation as specified in RFC--1483 [8]. For more information see RFC--1577 [11]. Cole, Shur Expires August 17, 1995 [Page 11] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 6.2 Ohta's "Conventional" Model The conventional model is layered and has the same network layer architecture as the standard IP model, hence it retains the IP subnet architecture. At the link layer, all types of ATM subnets are allowed. The basic difference between the Classical and the "Conventional" model is whether it is assumed that a router can relay IP packets cell by cell or not. Link layers are connected by routers but, when the two link layers are ATM, the routers are capable of forwarding cell-by-cell. This could provide a latency advantage depending on whether cell interleaving from multiple IP packets is allowed or not (e.g., an ATM AAL such as AAL3/4 would allow for cell interleaving, while AAL5 would not). This cell forwarding is accomplished through a higher level mapping, above the ATM VCI layer. 6.3 The SVC-based WATM Configuration (ROLC model) The SVC-based WATM is a NBMA network which may be part of a larger Internet, consisting of similar SVC-based WATM networks (which are not inter-connected at the ATM level) as well as Classical IP style subnets. While there is no particular restriction on the number of end systems, it is believed that this model is most useful for large number of end systems, e.g., up to at most a few hundreds of thousands, which o Support switched virtual connections (SVCs) as well as permanent virtual connections (PVCs), o May be directly connected, due to the existence of SVCs, o Do not all necessarily share a common IP-level (or L3) network prefix, o Support multiple subnetwork point of attachment (SNPA) address formats (four possible formats are allowed in UNI 3.0 [14]), o Support negotiations for parameters such as MTU size, methods of encapsulation, o Does not support an efficient broadcast/multicast mechanism for address resolution, o Is not part of a single administrative group and hence security is an issue, and o May be billed for circuit holding time. Cole, Shur Expires August 17, 1995 [Page 12] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 Figure 3: An SVC-based WATM configuration between End Systems which in fact could be Hosts or Routers. RFC--1620 [4] describes this and similar configurations in more detail, as well as associated problems and possible solution approaches. Figure 3 shows an example end-to-end configuration consisting of four components, three of which are ATM-technology- based, while the fourth is a standard IP subnetwork based on non-ATM technology. Since end-systems (either hosts or routers) attached to the ATM-based networks may communicate directly via ATM (subject to policy constraints), in this model such nodes may also communicate directly at the IP level without necessarily needing an intermediate router, even if end-systems do not share a common IP-level network prefix. Communication with end-systems on the non-ATM-based Classical IP subnet takes place via a router, following the Classical IP model. Many of the problems/issues associated with this configuration, which were originally being addressed in the IETF's IPLPDN working group and the IP over ATM working group, are now being addressed in the Routing over Large Clouds working group. Examples of work performed in the IPLPDN working group include short-cut routing (proposed by P. Tsuchiya) and directed ARP RFC--1433 [7] over SMDS subnets, and in the ROLC working group include distributed ARP server architectures and next hop resolution protocols in RFC--1735 [9], and NHRP [10]. Questions/Issues to be worked for this configuration include: o How can routing be optimized across multiple logical IP subnets over both a common ATM based and a non-ATM based infrastructure. E.g.in Figure 3, there are two gateways/routers between the SVC-based WATM and the non-ATM subnet. The optimal path from end-systems on any ATM-based subnet to the non ATM-based subnet is a function of the routing state information of the two Cole, Shur Expires August 17, 1995 [Page 13] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 routers. o How to incorporate policy routing constraints, o What is the proper coupling between routing and address resolution aspects particularly with respect to off-subnet communication, o What are the local procedures to be followed by hosts and routers. o Routing between end systems not sharing a common IP-level (or L3) network prefix, but able to be directly connected at the subnet level, o Defining the details for an efficient address resolution architecture including defining the procedures to be followed by clients and servers, (see RFC--1433 [7], RFC--1735 [9] and NHRP [10].) o Methods of encapsulation and multiplexing, (This issue is addressed in RFC--1483 [8].) o Defining the default MTU size, (This issue is addressed in RFC--1626 [2].) o Defining security procedures, o Support for IP multicasting, o Defining SVC optimization techniques, e.g., time-out mechanisms, o Negotiations of, e.g., MTU size, method of encapsulation, and o Special purpose SVCs for control/routing and high bandwidth data transfers. More complex ATM internets are envisioned (e.g., mesh connectivity among private and public networks), and solutions to networking over SVC-based WATM subnets must be able to support these complex internets and their attending problems. An additional complexity in supporting IP routing over these ATM internets lies in the multiplicity of subnetwork points of attachment address formats in UNI 3.0 [14]. NSAP modeled address formats only are supported on "private ATM" networks, while either 1) E.164 only, 2) NSAP modeled formats only, or 3) both are supported on "public ATM" networks. Further, while both the E.164 and NSAP modeled address formats are to be considered as subnetwork points of attachment, it seems that E.164 only networks are to be considered as subordinate to Cole, Shur Expires August 17, 1995 [Page 14] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 "private networks", in some sense. This leads to some confusion in defining an ARP mechanism in supporting all combinations of end-to-end scenarios (refer to the discussion in Appendix A on the possible scenarios to be supported by ARP). 6.4 Integrated Model The Classical IP model requires that IP routing be independent of the details of connectivity in an ATM sub-network. If ATM routing processes are present within the subnet, this implies that the user needs to install and manage two independent routing hierarchies (one for ATM, and one for IP). The Integrated model (proposed and under study within the Multiprotocol group of ATM Forum) considers a single routing protocol to be used for both IP and for ATM. A single routing information exchange is used to distribute topological information. The routing computation used to calculate routes for IP will take into account the topology, including link and node characteristics, of both the IP and ATM networks and calculates an optimal route for IP packets over the combined topology. Many issues exist with respect to the above proposal. While the potential exists to compute "better" routes, overall routing complexity (e.g., ensuring loop-free routing) is increased. 6.5 Peer Models Peer Models place IP routers/gateways on a peer basis with corresponding entities in an ATM cloud (where the ATM cloud may consist of a set of ATM networks, inter-connected via UNI or P-NNI interfaces). That is, ATM network entities and the attached IP hosts or routers exchange call routing information on a peer basis. Within the ATM cloud, ATM network level addressing (NSAP-style), call routing and packet formats are used. Peer models are being discussed in the Multiprotocol SWG of the ATM Forum. A rationale for these models is that due to the envisioned complexity of future ATM networks, the routing complexities will be similar to routing over complex internets. Rather than building in redundancy in routing complexities at the network and subnetwork levels, perhaps it is possible to imbed within the ATM network fabric IS (router) functionality. This is illustrated in Figure 4. Here the term "Single ATM Domain" refers to a collection of ATM switches from a single ATM switch vendor or a collection of ATM switches administered by a single authority. The routing function of the ATM-IS is only required during the connection set-up phase, and not in the data transfer phase following the connection establishment. Cole, Shur Expires August 17, 1995 [Page 15] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 Figure 4: The ATM Internet model imbeds within the ATM cloud network level routing features which in essence peers with traditional gateways or routers. There are numerous issues to be worked for this Peer Model including: o Defining a routing architecture which -- scales to the large size expected of the eventual ATM network, and -- supports TOS routing and IP options, and o Defining a functional architecture which -- scales to the large size expected of the eventual ATM network, -- supports the current status of the ATM Forum's standards in signalling, routing, etc., and -- allows a transition from subnet models to peer models. During the discussions of the IP over ATM working group, it was felt that the problems with the end-to-end peer model were much harder than any other model, and had more unresolved technical issues. While encouraging interested individuals/companies to research this area, it Cole, Shur Expires August 17, 1995 [Page 16] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 Figure 5: The ATM transition model assuming the presence of gateways or routers between the ATM subnets and the ATM peer networks. was not an initial priority of the working group to address these issues. The ATM Forum Network Layer Multiprotocol Working Group is discussing this model. 6.6 Transition Models Finally, it is useful to consider transition models, lying somewhere between the Classical IP Models and the Peer Models. Some possible architectures for transition models have been suggested by Fong Liaw. Others are possible, for example Figure 5 showing a Classical IP transition model which assumes the presence of gateways between ATM subnets and ATM Peer networks. 7 Application of the Working Group's and Related Documents The IP Over ATM Working Group has generated several Internet-Drafts and RFCs. This section identifies the relationship of these and other related documents to the various IP Over ATM Models identified in this document. The Drafts and RFCs produced to date are the following references, RFC--1483 [8], RFC--1577 [11], RFC--1626 [2], RFC--1755 [13], IPMC [1] and NHRP [10]. Table 1 gives a summary of these documents and their relationship to the various IP Over ATM Models. Cole, Shur Expires August 17, 1995 [Page 17] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 Documents_|Summary______________________________________________________ RFC 1483 |How to identify/label multiple packet/frame-based proto- |cols multiplexed over ATM AAL5. Applies to any model |dealing with IP over ATMAAL5. RFC1577 |Model for transporting IP and ARP over ATM AAL5 in a |subnetwork where all nodes share a common IP network |prefix. Includes ARP server/Inv-ARP packet formats and |procedures for SVC/PVC subnets. RFC1626 |Specifies default IP MTU size to be used with ATM AAL5. |Requires use of PATH MTU discovery. Applies to any model |dealing with IP over ATM AAL5. RFC 1755 |Defines how implementations of IP over ATM should use ATM |call control signaling procedures, and recommends values |of mandatory and optional IEs focusing particularly on the |Classical IP model. ARM94 |Defines how to support IP multicast in Classical IP model |using either (or both) meshes of point-to-multipoint ATM |VCs, or multicast server(s). KAT94 |Describes a protocol that can be used by hosts and routers |to determine the NBMA next hop address of a destination |in "NBMA connectivity" of the sending node. If the |destination is not connected to the NBMA fabric, the |IP and NBMA addresses of preferred egress points are |returned. Applies to the ROLC model. Table 1: Summary of WG Documents Cole, Shur Expires August 17, 1995 [Page 18] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 8 Conclusions This document describes two ATM-based subnet models, namely, an SVC-based LATM (LATM) and a PVC-based WAN ATM (PVC-based WATM). Furthermore, this document lists several of the end-to-end IP over ATM architectures which have been discussed and the distinguishing characteristics of each. The End-to-end models discussed include the Classical IP model, Ohta's "Conventional" model, the ROLC model, the Integrated Model, and Peer models. The major issues pertaining to the various models have been listed, identifying which ones are largely resolved, and which ones are as yet unresolved. It is proposed that in general current or future IP over ATM subnet or end-to-end models should be worked separately to simplify the work into more manageable steps. On the other hand, where a common functionality applies across many models (e.g., encapsulation), a single activity focused on this subject spanning multiple models is also a recommended approach. Acknowledgments: This draft is the direct result of the numerous discussions of the IP over ATM Working Group of the Internet Engineering Task Force. The authors also had the benefit of several private discussions with H. Nguyen of AT&T Bell Laboratories. Brian Carpenter of CERN was kind enough to contribute the TULIP and TUNIC sections to this draft. Grenville Armitage of Bellcore and Curtis Villamizar of ANS were kind enough to contribute the sections on VC binding, encapsulations and the use of B-LLI information elements to signal such bindings. The text of Appendix A was pirated liberally from Anthony Alles' of Cisco posting on the IP over ATM discussion list (and modified at the authors' discretion). This draft also has benefitted from numerous suggestions from John T. Amenyo of ANS, Joel Halpern of Newbridge, and Andy Malis of Ascom-Timplex. Authors' Addresses: Robert G. Cole AT&T Bell Laboratories 101 Crawfords Corner Road, Rm. 3L-533 Holmdel, NJ 07733 Phone: (908) 949-1950 Fax: (908) 949-8887 Email: rgc@qsun.att.com Cole, Shur Expires August 17, 1995 [Page 19] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 David Shur AT&T Bell Laboratories 101 Crawfords Corner Road, Rm. 1F-338 Holmdel, NJ 07733 Phone: (908) 949-6719 Fax: (908) 949-5775 Email: d.shur@att.com References [1] G. Armitage. Support for multicast over uni 3.1 based atm networks. Internet Draft (Work in Progress) draft-ietf- ipatm-ipmc-04.txt, Internet Engineering Task Force, February 1995. [2] R. Atkinson. Default IP MTU for use over ATM AAL5. Request for Comments (Experimental) RFC 1626, Internet Engineering Task Force, may 1994. [3] R. Braden and J. Postel. Requirements for internet gateways. Request for Comments (Standard) RFC 1009, Internet Engineering Task Force, June 1987. Obsoletes RFC0985. [4] R. Braden, J. Postel, and Y. Rekhter. Internet architecture ex- tensions for shared media. Request for Comments (Informational) RFC 1620, Internet Engineering Task Force, may 1994. [5] T. Bradley and C. Brown. Inverse address resolution protocol. Request for Comments (Proposed Standard) RFC 1293, Internet Engineering Task Force, January 1992. [6] T. Bradley, C. Brown, and A. Malis. Multiprotocol interconnect over frame relay. Request for Comments (Draft Standard) RFC 1490, Internet Engineering Task Force, July 1993. Obsoletes RFC1294. [7] J. Garrett, J. Hagan, and J. Wong. Directed ARP. Request for Comments (Experimental) RFC 1433, Internet Engineering Task Force, March 1993. [8] J. Heinanen. Multiprotocol encapsulation over ATM adaptation layer 5. Request for Comments (Proposed Standard) RFC 1483, Internet Engineering Task Force, July 1993. [9] J. Heinanen and R. Govindan. Nbma address resolution protocol (narp). Request for Comments (Experimental) RFC 1735, Internet Engineering Task Force, December 1994. Cole, Shur Expires August 17, 1995 [Page 20] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 [10] D. Katz and D. Piscitello. Nbma next hop resolution protocol (nhrp). Internet Draft (Work in Progress) draft-ietf- rolc-nhrp-03.txt, Internet Engineering Task Force, November 1994. [11] M. Laubach. Classical IP and ARP over ATM. Request for Comments (Proposed Standard) RFC 1577, Internet Engineering Task Force, January 1994. [12] J. Mogul and S. Deering. Path MTU discovery. Request for Comments (Draft Standard) RFC 1191, Internet Engineering Task Force, November 1990. [13] M. Perez, F. Liaw, D. Grossman, A. Mankin, and A. Hoffman. Atm signalling support for ip over atm. Request for Comments (Informational) RFC 1755, Internet Engineering Task Force, January 1995. Stale References: [14] ATM Forum, "ATM User-Network Interface Specification", Version 3.0, PTR Prentice Hall, ISBN 0-13-225863-3, September 1993. Appendix A: Potential Interworking Scenarios to be Supported by ARP The architectural model of the VC routing protocol, being defined by the Private Network-to-Network Interface (P-NNI) working group of the ATM Forum, categorizes ATM networks into two types: o Those that participate in the VC routing protocols and use NSAP modeled addresses UNI 3.0 [14] (referred to as private networks, for short), and o Those that do not participate in the VC routing protocol. Typically, but possibly not in all cases, public ATM networks that use native mode E.164 addresses UNI 3.0 [14] will fall into this later category. The issue for ARP, then is to know what information must be returned to allow such connectivity. Consider the following scenarios: Cole, Shur Expires August 17, 1995 [Page 21] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 o Private host to Private Host, no intervening public transit network(s): Clearly requires that ARP return only the NSAP modeled address format of the end host. o Private host to Private host, through intervening public networks: In this case, the connection setup from host A to host B must transit the public network(s). This requires that at each ingress point to the public network that a routing decision be made as to which is the correct egress point from that public network to the next hop private ATM switch, and that the native E.164 address of that egress point be found (finding this is a VC routing problem, probably requiring configuration of the public network links and connectivity information). ARP should return, at least, the NSAP address of the endpoint in which case the mapping of the NSAP addresses to the E.164 address, as specified in [14], is the responsibility of ingress switch to the public network. o Private Network Host to Public Network Host: To get connectivity between the public node and the private nodes requires the same kind of routing information discussed above - namely, the directly attached public network needs to know the (NSAP format) ATM address of the private station, and the native E.164 address of the egress point from the public network to that private network (or to that of an intervening transit private network etc.). There is some argument, that the ARP mechanism could return this egress point native E.164 address, but this may be considered inconsistent for ARP to return what to some is clearly routing information, and to others is required signaling information. In the opposite direction, the private network node can use, and should only get, the E.164 address of the directly attached public node. What format should this information be carried in? This question is clearly answered, by Note 9 of Annex A of UNI 3.0 [14], Version 2.4 (passed by ballot recently to become Version 3.0), vis: "A call originated on a Private UNI destined for an host which only has a native (non-NSAP) E.164 address (i.e. a system directly attached to a public network supporting the native E.164 format) will code the Called Party number information element in the (NSAP) E.164 private ATM Address Format, with the RD, AREA, and ESI fields set to zero. The Called Party Subaddress information element is not used." Hence, in this case, ARP should return the E.164 address of the public ATM station in NSAP format. This is essentially implying an algorithmic resolution between the native E.164 and NSAP addresses of directly attached public stations. Cole, Shur Expires August 17, 1995 [Page 22] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 o Public network host to Public network host, no intervening private network: In this case, clearly the Q.93b requests would use native E.164 address formats. o Public network host to Public network host, intervening private network: same as the case immediately above, since getting to and through the private network is a VC routing, not an addressing issue. So several issues arise for ARP in supporting arbitrary connections between hosts on private and public network. One is how to distinguish between E.164 address and E.164 encoded NSAP modeled address. Another is what is the information to be supplied by ARP, e.g., in the public to private scenario should ARP return only the private NSAP modeled address or both an E.164 address, for a point of attachment between the public and private networks, along with the private NSAP modeled address. Appendix B: Encapsulations and Lower Layer Identification: Data encapsulation, and the identification of VC endpoints, constitute two important issues that are somewhat orthogonal to the issues of network topology and routing. The relationship between these two issues is also a potential sources of confusion. In conventional LAN technologies the 'encapsulation' wrapped around a packet of data typically defines the (de)multiplexing path within source and destination nodes (e.g. the Ethertype field of an Ethernet packet). Choice of the protocol endpoint within the packet's destination node is essentially carried 'in-band'. As the multiplexing is pushed towards ATM and away from LLC/SNAP mechanism, a greater burden will be placed upon the call setup and teardown capacity of the ATM subnet. This may result in some questions being raised regarding the scalability of these lower level multiplexing options. With the ATM Forum UNI version 3.1 service the choice of endpoint within a destination node is made 'out of band' - during the Call Setup phase. This is quite independent of any in-band encapsulation mechanisms that may be in use. The B-LLI Information Element allows Layer 2 or Layer 3 entities to be specified as a VC's endpoint. When faced with an incoming SETUP message the Called Party will search locally for an AAL User that claims to provide the service of the layer specified in the B-LLI. If one is found then the VC will be accepted (assuming other conditions such as QoS requirements are also met). Cole, Shur Expires August 17, 1995 [Page 23] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 Figure 6: AAL5 PDU is an encapsulated IP packet An obvious approach for IP environments is to simply specify the Internet Protocol layer as the VCs endpoint, and place IP packets into AAL--SDUs for transmission. This is termed 'VC multiplexing' or 'Null Encapsulation', because it involves terminating a VC (through an AAL instance) directly on a layer 3 endpoint. However, this approach has limitations in environments that need to support multiple layer 3 protocols between the same two ATM level endpoints. Each pair of layer 3 protocol entities that wish to exchange packets require their own VC. RFC--1483 [8] notes that VC multiplexing is possible, but focuses on describing an alternative termed 'LLC/SNAP Encapsulation'. This allows any set of protocols that may be uniquely identified by an LLC/SNAP header to be multiplexed onto a single VC. Figure 6 shows how this works for IP packets - the first 3 bytes indicate that the payload is a Routed Non-ISO PDU, and the Organizationally Unique Identifier (OUI) of 0x00-00-00 indicates that the Protocol Identifier (PID) is derived from the EtherType associated with IP packets (0x800). ARP packets are multiplexed onto a VC by using a PID of 0x806 instead of 0x800. Whatever layer terminates a VC carrying LLC/SNAP encapsulated traffic must know how to parse the AAL--SDUs in order to retrieve the packets. The recently approved signalling standards for IP over ATM are more explicit, noting that the default SETUP message used to establish IP over ATM VCs must carry a B-LLI specifying an ISO 8802/2 Layer 2 (LLC) entity as each VCs endpoint. More significantly, there is no information carried within the SETUP message about the identity of the layer 3 protocol that originated the request - until the packets begin arriving the terminating LLC entity cannot know which one or more higher layers are packet destinations. Cole, Shur Expires August 17, 1995 [Page 24] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 Figure 7: LLC/SNAP encapsulation allows more than just IP or ARP per VC. Taken together, this means that hosts require a protocol entity to register with the host's local UNI 3.1 management layer as being an LLC entity, and this same entity must know how to handle and generate LLC/SNAP encapsulated packets. The LLC entity will also require mechanisms for attaching to higher layer protocols such as IP and ARP. Figure 7 attempts to show this, and also highlights the fact that such an LLC entity might support many more than just IP and ARP. In fact the combination of RFC 1483 LLC/SNAP encapsulation, LLC entities terminating VCs, and suitable choice of LLC/SNAP values, can go along way towards providing an integrated approach to building multiprotocol networks over ATM. The processes of actually establishing AAL Users, and identifying them to the local UNI 3.1 management layers, are still undefined and are likely to be very dependent on operating system environments. Two encapsulations have been discussed within the IP over ATM working group which differ from those given in RFC--1483 [8]. These have the characteristic of largely or totally eliminating IP header overhead. These models were discussed in the July 1993 IETF meeting in Amsterdam, but have not been fully defined by the working group. Given a single hop configuration between Sub-ES as shown in Figure 1 (in the main text above), they both assume that following name resolution, address resolution, and SVC signaling, an implicit binding is established between entities in the two Sub-ESes. In this case full IP headers (and in particular source and destination addresses) are not required in each data packet. Cole, Shur Expires August 17, 1995 [Page 25] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 o The first model is "TCP and UDP over Lightweight IP" (TULIP) in which only the IP protocol field is carried in each packet, everything else being bound at call set-up time. In this case the implicit binding is between the IP entities in each Sub-ES. Since there is no further routing problem once the binding is established, since AAL5 can indicate packet size, since fragmentation cannot occur, and since ATM signaling will handle exception conditions, the absence of all other IP header fields and of ICMP should not be an issue. Entry to TULIP mode would occur as the last stage in SVC signaling, by a simple extension to the encapsulation negotiation described in RFC--1755 [13]. TULIP changes nothing in the abstract architecture of the IP model, since each subnet ES still has an IP address which is resolved to an ATM address. It simply uses the point-to-point property of VCs to allow the elimination of some per-packet overhead. The use of TULIP could in principle be negotiated on a per-SVC basis or configured on a per-PVC basis. o The second model is "TCP and UDP over a Nonexistent IP Connection" (TUNIC). In this case no network-layer information is carried in each packet, everything being bound at virtual circuit set-up time. The implicit binding is between two applications using either TCP or UDP directly over AAL5 on a dedicated VC. If this can be achieved, the IP protocol field has no useful dynamic function. However, in order to achieve binding between two applications, the use of a well-known port number in classical IP or in TULIP mode may be necessary during call set-up. This is a subject for further study and would require significant extensions to the use of SVC signaling described in RFC--1755 [13]. TULIP/TUNIC can be presented as being on one end of a continuum opposite the SNAP/LLC encapsulation, with various forms of null encapsulation somewhere in the middle. The continuum is simply a matter of how much is moved from in-stream demultiplexing to call setup demultiplexing. The various encapsulation types are presented in Table 2. Cole, Shur Expires August 17, 1995 [Page 26] INTERNET-DRAFT IP over ATM: A Framework Document February 17, 1995 Encapsulation_Method_|In_setup_message_________|Demultiplexing___________ SNAP/LLC |nothing |source and destination | |address, protocol family, | |protocol, ports NULL encapsulation |source and destination, |source and destination, |protocol family |protocol, ports TULIP |source and destination, |protocol |protocol family | TUNIC - A |source and destination, |ports |protocol family, | |protocol | TUNIC - B |source and destination, |nothing |protocol family, | |protocol, ports | Table 2: Summary of Encapsulation Types Cole, Shur Expires August 17, 1995 [Page 27]