Introducing ATM in the Internet. M. Baldi and S. Gai

Transcription

1 Introducing in the Internet Lavoro completo M. Baldi and S. Gai Dipartimento di Automatica e Informatica Politecnico di Torino Corso Duca degli Abruzzi, Torino - Italy Phone: Fax: {mbaldi, silvano}@polito.it Abstract This work provides a survey of the main approaches proposed so far by both standardization bodies and manufacturers, for the exploitation of technology into the Internet. The integration level between the and protocols is used as the driving thread in the presentation: solutions conforming to the overlay model, which considers as a data-link technology over which packets are sent, are considered first. Then, solutions providing various levels and flavors of integration are taken into account. In the characterization of each approach we focus on its ability to provide guaranteed quality of service. Area di interesse: e Internet

2 1. Introduction Internet is growing up: not only is the number of its users increasing daily, but the applications they want to run are also becoming ever more demanding. Multimedia applications require high bandwidth, constant-delay services, whose adequate support is being ensured by increasing the bandwidth of links connecting routers, and refining the way routers operate. The Internet Engineering Task Force (IETF) is developing a new version of, called v6 or ng [1] to cope with both the growing dimension of Internet (the addressing scheme has been extended) and new applications (a data flow identifier has been added into the packet header). IETF has also been working on the Integrated Services Internet [2]: an integrated services model is being developed for Internet and the Quality of Service (QoS) concept is being introduced. The model uses routers that apply complex packet scheduling and queuing schemes, and applications that exploit reservation protocols to demand the QoS they need from the network. A key component of the Integrated Services Internet is the Resource ReSerVation Protocol (RSVP) [3] currently in the process of development. This is designed to allow an application describe the QoS it needs from the network and propagate the request along the path its packets will follow. Routers calculate the amount of local resources they need to provide it and either reserve these resources, or announce the reduced service they can provide. QoS request QoS request Applications (e.g., video conference) Network layer protocol (e.g., with RSVP) Network infrastructure (e.g., ) QoS guarantee QoS guarantee Figure 1: QoS guarantee in the Internet and. Asynchronous Transfer Mode (), the technology recommended by ITU-T for deployment in the Broadband-Integrated Services Digital Network (B-ISDN) [4], seems suitable for this scenario. It was expressly designed to support multimedia traffic, i.e., to provide applications with predefined QoS guarantees and possibly high-bandwidth. A key issue is the mapping of applications needs onto QoS provided by the underlying network. As shown in Figure 1, applications request QoS through high-layer mechanisms (e.g., RSVP), and their requests are mapped onto a lower-layer QoS request; the QoS guarantee provided by the network can be used by the layer to provide applications with the QoS they desire. Effective operation of the Integrated Services Internet over thus requires deep integration between TCP/ protocols and [5]. Some general questions concerning the introduction of in Internet are tackled in Section 2. The main models for operating over or and are presented in the following sections. Conclusions are drawn in Section and Figure 2 shows a taxonomy of the main approaches to the introduction of in the Internet which devise various levels of integration. Overlay or subnet models use networks instead of conventional data link layers to carry packets between routers and hosts. The many questions posed by the differences between the services provided by and those provided by conventional data link protocols can be addressed via two approaches: LAN emulation: the network emulates the behavior of a legacy (IEEE 802) LAN providing the very services conventional network layer protocols were designed to exploit [6]; native mode operation: the protocol and its subsidiary protocols are adapted to exploit the services provided by networks. The first approach is backed by Forum [7]. It is applicable to any network layer protocol and allows the quick and inexpensive introduction of into existing networks, but does not provide any integration between and, and hides all the characteristics of (e.g., QoS guarantee) to upper layers (finally to applications). This approach is not specifically related to Internet and is not dealt with in this paper. 1

3 Switching CSR forwarding addressing routing Tag Switching IRA IIAA ARIS I-PNNI over LANE ARP C NHRP NHRP model LANE MPOA Figure 2: Taxonomy of Approaches for Introduction of in the Internet. The solutions for native-mode operation proposed by IETF yield various levels of integration according to 's role. At the lowest level there is the Classical over model which devises the ARP protocol in place of the ARP protocol which requires the data-link layer to provide a broadcast service, not supported by. The Next Hop Resolution Protocol (NHRP) is exploited in place of the ARP protocol in the NHRP model. This yields wider exploitation of switching to carry packets. The Multi-Protocol Over solution considers router forwarding coupled with emulation of legacy LAN services as the default way for carrying datagrams. Nevertheless, when a packet flow is identified that would benefit from minimal exploitation of routing along the path to the destination, a shortcut connection is open to an address obtained through NHRP. The other solutions shown in Figure 2 are based on integration instead of overlaying. Peer models feature addressing integration. The / Integrated Routing and Addressing (IRA) model and the Integrated and Architecture (IIAA) use the and the addressing schemes, but addresses are algorithmically mapped on addresses. Tag Switching and ARIS identify destinations through addresses and do not use signaling (and consequently addresses). Switching and Cell Switch Router (CSR) as multilayer switching solutions integrate switching and level forwarding. The router forwards packets according to level routing information and monitors the traffic to detect packet flows that would benefit from switching; these flows are eventually switched at the level. Lastly, the Integrated P-NNI approach integrates and routing by exploiting a single routing protocol to carry both and reachability information. Exploitation of end-to-end services is not always the best solution [9]: many applications (e.g., electronic mail or file transfer) do not require QoS guarantees, and the most cost-effective way of carrying their traffic is the packet-based forwarding provided by routers. This allows a high degree of multiplexing and communication resource usage. UDP AAL TCP applications transport network data-link PHY Figure 3: Basic protocol architecture for exploiting in the Internet. Transferring packets over networks requires an encapsulation scheme. As shown in Figure 3, an adaptation layer is needed between and, if only to segment packets and reassemble them in cells 1. IETF is proposing the deployment of AAL5 on account of its easy implementation and very limited overhead: its service data unit is bytes long, but the recommended maximum transmission unit is 9180 bytes. Various solutions for multiplexing packet flows between two nodes are provided by IETF: a single virtual circuit (VC) is set up between a couple of nodes and an LLC type 1 header with SNAP extension is used [10]; alternatively, many VCs can be set up between a couple of nodes and terminated at either the network layer protocol entities [10], or the transport layer protocol entities, or the applications [11]. 1 Encapsulating packets into cells (48 bytes of payload) obviously makes no sense. 2

4 3. Classical over When one or more Logical Subnets (LISs) are identified on an network, according to the Classical over model [12], two nodes belonging to the same LIS communicate directly, i.e., they set up a connection between them and send packets through it; nodes belonging to different LISs communicate through a router, i.e., VCs never cross LIS borders. The main problem in deploying the classical routing model over networks stems from the unfeasibility of the conventional ARP, which is based on broadcast transmission. RFC 1577 [12] defines ARP and InARP (Inverse ARP) 2 protocols and describes their operation over both networks supporting only permanent VCs (e.g., a public WAN), and those supporting switched VCs through the UNI 3.1 signaling protocol. In the first case, direct address resolution is unnecessary, as each node just needs to learn the address of the nodes it is connected to through permanent VCs. In the second, an ARP server must operate in each LIS; it builds and updates a table, whose entries map addresses of all LIS nodes to their respective addresses. Each host and router is configured with the address of the ARP server(s) responsible for its LIS(s), and sets up a VC with the server(s) as soon as it begins to operate on the LIS. LIS #1 S1. S1. S1 1 ARP_REQUEST ARP_REPLY ARP Server... S4. -> S4. S1. -> S1.... S3 2 S2 4 subnet 3 S4 S4. S4. Figure 4: ARP Server and client interaction. Prior to sending a packet to the next hop 3, a node submits an ARP request (step 1 in Figure 4) to the ARP server responsible for its LIS, the server sends back an ARP response packet containing the required address (step 2), and the node sets up a VC towards the next hop (step 3 or 4). The node saves the address mapping in a local table for later use; the entries of both ARP servers and clients tables are subject to aging. The Classical over model reveals its weakness when more than one LIS is identified on a single network: switching is used only inside each LIS, while packets exchanged between LISs always pass through routers. 4. Next Hop Resolution Protocol To draw the greatest advantage from transferring packets over networks, routers should only be employed to cross the boundaries of physical networks, and not to route packets inside a single network. With hop-by-hop redirection, the source uses the path with the least number of hops only after a number of packets have been sent; with extended routing, the routers alone learn which destinations are directly reachable and which is their last hop router. The Next Hop Resolution Protocol (NHRP) [13] proposed by the ROLC working group in a draft specification provides a sender in a single shot with the best cut-through route towards a destination. NHRP is an address resolution protocol expressly designed for operation over large Non-Broadcast Multiple Access (NBMA) networks 4 ; It can either completely replace ARP or coexist with it during transition phases. 2 The ARP specification is derived from the more general NBMA-ARP (NARP) specification proposed by the Routing Over Large Clouds (ROLC) working group for operation over Non-Broadcast Multiple Access (NBMA) networks. 3 The next hop is chosen according to the classical routing rules, i.e., it is in the node's LIS. 4 NHRP was designed to operating with any kind of data-link technology and address format. Only its reference to is dealt with in what follows. 3

5 H1 R1 H3 R3 H6 LIS #1 H2 subnet H5 H4 LIS #4 R2 LIS #2 R4 LIS #3 LIS #5 H7 H8 H9 SH0 Figure 5: Connection exploitation with NHRP. NHRP operates through Next Hop Servers (NHSs) that interact to get the information needed to respond to address resolution requests submitted by clients. A node wishing to send an packet submits an NHRP resolution request for the address of the destination, regardless of whether or not this is in the sender's LIS 5. NHRP provides the address of the next hop towards the destination; the sender (H1 or H2 in Figure 5) uses this address to set up a VC with this next hop and transmits the packets on the VC. If the destination is on the sender s network and hence it is possible to set up a VC between them, the next hop is the final destination itself. If the destination is not directly reachable through a VC (H7 in Figure 5), the next hop is an egress router able to forward packets to the destination (R2 in Figure 5). As routers, too, exploit NHRP, communications between egress routers, i.e., the forwarding of packets whose source and destination are outside the network, are also optimized; e.g., packets from H8 to H9 in Figure 5 are transmitted over the VC between R2 and R NHRP operation Each NHS is responsible for knowing the correspondence between address and address of a set of nodes which is named a Local Address Group (LAG); ownership to the LAG is configured in the server and the clients. NHSs implement a distributed data base and interact with each other to satisfy resolution requests from clients. NHRP requests generated by a client that cannot be satisfied by the first NHS they travel through the network across several NHSs until they reach the one responsible for the address contained in the request. This NHS generates a NHRP reply packet and sends it back to the client along the path followed by the request. Intermediate NHSs forward the reply and cache the information it contains. They can then answer subsequent requests concerning the given address by themselves. Cached information cannot be used to satisfy NHRP requests whose response is specified to be authoritative. It is also possible to have the NHS generate a reply and send it direct to the originator of the request; this procedure reduces the response time, but does not allow the caching and non-authoritative reply mechanisms to be put up. On receiving the NHRP reply, the client caches the destination address and next hop address mapping just learned, and can then send subsequent packets to the same destination without issuing other NHRP resolution requests. The information cached by both clients and intermediate NHSs is subject to aging. As the next hop resolution procedure can be lengthy, the NHRP specification allows the source to begin the transmission by sending the first packets through the default router. Alternatively, the source can either delay the transmission of the first packets until the NHRP reply has been received, or discard them and thus leaving the responsibility for retransmitting them later to upper-layer protocols. 4.2 NHSs localization and operation Each NHS takes a routing decision based on either static configured or dynamically learned information. Location of NHS function in each router allows NHRP requests to be routed along the path used for data packets and calculated with conventional routing protocols. The NHRP request packet finally hits the router/nhs responsible for the to address mapping that generates the NHRP reply. The clients are 5 Note that when classical over and ARP are deployed, the source host requires resolution of the address of either the destination or default router, depending on whether the destination is in the sender's or another respectively. 4

6 configured to send NHRP requests to their default router or the one determined by their local routing decision process according to the address to be resolved. All egress routers have NHS functions, and NHRP requests are not forwarded outside the network in order to deny level connectivity between stations in different logical subnets (i.e., communications across the border must only be performed through routers). As routers operate in the network, NHRP-non-capable stations can send packets through them, i.e., they coexist and interoperate with NHRP-capable stations, and these can forward data packets to the chosen router while waiting for completion of the NHRP address resolution. This deployment mode requires all routers on the subnet to have NHS functions. Gradual introduction of NHRP into a network running the classical over model is ensured by statically configuring NHSs and NHRP-capable hosts with the addresses of the NHSs to which NHRP requests are to be forwarded. Introduction of may involve several steps that require more and more substantial changes and increasingly enhance performance. When is first introduced in TCP/ networks, one or more legacy physical subnetworks are replaced by an network in which is operated according to the classical over model. Hosts and routers must be equipped with adapters, and simple changes in their ARP software allow them to work. When NHRP-capable hosts are introduced, static configuration and a small number of NHSs are enough to allow them to operate. As a growing number of routers is enhanced with NHRP functions, NHS addresses statically configured into hosts can be removed. 5. Multi-Protocol Over The Multi-Protocol Over (MPOA) [14] approach exploits both LANE over and NHRP to carry network layer packets over networks. The approach is general and could be used for any protocol; so far guidelines have been given for the exploitation of MPOA with and X 6. Hosts and edge devices, i.e., devices connected to legacy LANs (e.g., bridges), contain one or more MPOA Clients (MPCs). Hosts on the same virtual LAN, being them on the network or on a legacy LAN connected to an edge device, use LANE to exchange data. Packets directed outside a LAN are delivered through LANE to a router for being forwarded along their default path to the final destination which is calculated by the MPS using usual routing protocols. In this scenario the MPC co-located with an edge device works as a bridge forwarding MAC frames to their destination using LANE services. MPCs monitor their traffic in order to detect flows; flow detection can be based on various criteria and information carried in the header as well as higher layer headers can be used for the purpose. Whenever a flow is identified that would benefit from a direct connection to the destination, the MPC uses an NHRP based protocol to identify the other end of the intended VC. The MPC sends a query to the MPOA server (MPS) embedded in the router on the path towards the destination. The query contains the address of the destination of the flow and reply from the MPS contains the address of either the destination or the edge device through which it is better reachable. The MPC uses the address to open an MPOA shortcut VC over which it forwards the data flow. The MPS is co-located with an NHS which can answer to NHRP requests or forward them along the path towards the contained destination. The mechanism for getting the response is as the one specified by the NHRP model (see Section 0) except that the request is modified as it was coming from the MPS. This assures that the response is returned to the MPS which will then generate the answer to the MPC. The answer can carry additional information with respect to standard NHRP (e.g., a tag that can be used by the destination MPC to more swiftly forward the packet). From the point of view of hosts located outside the network, the former looks like a distributed router: edge devices play the role of the interfaces receiving packets from the legacy LAN(s) to which they are connected. Packets are forwarded to the MPS (playing the role of a route processor) which routes them to the proper egress edge device according to the information devised through network layer routing protocols. When the MPC co-located with and edge device identifies a packet flow, it interacts with the MPS in order to setup a shortcut path to the egress edge device in order to improve the performance of the distributed router and decrease the packet processing load on the MPS. 6. Peer models Peer models aim at keeping and at the same level, in contrast to overlay models which consider using the servicing provided by. Two solutions have been developed by standardization bodies so far: the / Integrated Routing and Addressing (IRA) model by IETF [15] and the Integrated and architecture by Forum [16]. The huge difficulties involved in their refinement and application, however, have caused them to be regarded as of non-primary interest by IETF and Forum, respectively. 6 In this section MPOA is described as an approach for exploitation of in networks only. 5

7 Two proprietary solutions are getting much attention thanks to their simplicity and immediate applicability: Tag Switching [17] by Cisco Systems and ARIS [18] by IBM. These approaches use addressing and routing to find the path through the network and use switching to move data along the chosen path. These approaches are sometimes categorized as multilayer switching approaches (see Section 7): we do not use these categorization because both Tag Switching and ARIS forward packets at the level only, i.e., the switching they perform is not multilayer. Nevertheless, since these approaches have many commonalties with multilayer switching ones, are compared with them in Section Peer Models by IETF and Forum Both IETF s and Forum s peer models propose that or v6 addresses be algorithmically mapped on NSAP formatted private addresses; this precludes the need for an address resolution protocol (like ARP or NHRP) and allows routers and hosts to require a connection set up using mapped addresses. They differ in the way and level reachability information is propagated, i.e., how switches and routers interact. The IRA model proposes that the same hierarchical prefix routing be used for both and : as the same address prefix identifies an entity at both the and level, all reachability information is propagated by switches through P-NNI. Routers do not use P-NNI, but employ the Prefix Route Exchange (PRE) protocol to inform their directly connected switch about the address prefixes they know, and receive information about the address prefixes learned by the switch through P-NNI. Switches propagate reachability information received through PRE as well as level information without being able to distinguish them. When a connection setup is required, the SEL field of the destination address specifies whether the end point is the or the level. The request is routed by switches and if an destination is outside the network, the request is forwarded to the router that advertised the address prefix of the destination. In the integrated and architecture, -connected routers run P-NNI to know the network topology, but do not route signaling messages 7. Routers do not exchange level routing protocol packets with other routers, but communicate with directly connected switches through the P-NNI routing protocol. Routers connected to conventional subnets run ordinary Internet routing protocols and may redistribute information into the subnets through the P-NNI protocol. To send packets, a host, as well as an ingress router, requires a connection to the mapped address of the destination; network nodes correctly route the request according to (both and level) reachability information gathered through the P-NNI routing protocol. The resulting VC is terminated onto either the ultimate destination, or the router that announced the best route towards it. 6.2 Tag Switching Cisco Systems proposes a general approach (not specifically designed for and ) in which tag switches forward packets according to a tag prepended to each packet [17]. Tag switches operate label-swapping at high packet rates by using the tag as an index to their forwarding table. The tag is assigned to packets according to the route they have to follow. When dealing with, the tag has not to be prepended to packets: the virtual circuit identifier (VCI) and virtual path identifier (VPI) can be used by tag switches to forward cells. The main difference between switches and tag switches is the way forwarding tables are built up. The former create a new entry in response to a signaling procedure usually initiated by the network user. The latter use routing protocols to discover the path towards every destination and then agree with neighbor tag switches on the incoming and outgoing tags (VPI/VCI pairs) to be deployed for each destination. Each pair of tags constitutes an entry in the forwarding table. Looking from the network point of view, a full mesh of VCs is built among all the destinations; thus, unscalability is the main Tag Switching problem. It can be overcome by associating tags to the next-hop ( router) instead of associating them to ultimate destinations. This rises the VC merging problem: packets are encapsulated into AAL5 protocol data units whose cells are interleaved on the same link using the same VC identifier, i.e., when the next-hop receives them is not able to discriminate among cells belonging to different packets. Many solutions, each with its shortcomings, are being proposed to solve the VC merging problem; so far none of them has showed to outperform the others. 6.3 Aggregated Route-based Switching (ARIS) ARIS [18] is based on exploitation of Integrated Switching Routers (ISRs) which are capable of forwarding packets at the level, i.e., cell by cell. ISRs at the border of the network are identified by an egress 7 This prevents a VC from being established through an router and its cells from being encapsulated into packets. 6

8 identifier and an ISR must have a VC to each egress ISR. Since many destinations can be reached through the same egress ISR, the approach has better scalability features than Tag Switching. Nevertheless, ARIS must cope with the VC merge problem. The protocol used to setup VCs guarantees against routing loops. 7. Multilayer Switching A number of proprietary approaches have recently appeared which pursue a deep integration between routing and switching. These approaches have relevant differences, but they share the goal of coupling the unique functions of routers with the high-speed, low-latency features of switches, thus reducing the delay and delay variation experienced by packets that traverse a router. In this section these approaches are briefly described and their possible application in the Internet is discussed; nevertheless, a detailed comparative analysis is outside the scope of this work. 7.1 Switching Ipsilon has proposed a multilayer routing approach [19] based on switches which are composed of two logically (in current implementations also physically) separated functions: switch and switch controller. traffic flows between two switches through a default VC which traverses the switch and is terminated at the two switch controllers, as show in Figure 6. They forward packets according to an routing table and perform flow classification in order to identify packet flows and decide, according to some configured policy, whether they would benefit from level forwarding. Default VC Dedicated VC Figure 6: switch working principle. In this latter case, the switch controller exploits the Ipsilon Flow Management Protocol (IFMP) to ask the neighbor switch controller to use a different VC to carry the data flow. The switch can get a similar request from the other neighbor switch controller and consequently begin forwarding the corresponding data flow on a VC different from the default one. At this point, the switch controller programs the switch through the Generic Switch Management Protocol (GSMP) so that it forwards the data flow at the level, i.e., it switches cells from the incoming VC to the outgoing VC. As a result packets flow through an VC which has been created with a soft-state mechanism and without using signaling. When packets flow ceases, the VC is torn down by the switch which removes the binding between the incoming and outgoing VC identifiers. 7.2 Cell Switch Router A pair of Cell Switch Routers (CSRs) [20] is connected by one default VC and zero or more dedicated VCs, as shown in Figure 7; VCs can be either permanent or switched, and are managed according to the over model in use over the network. CSRs can forward packets from an incoming to an outgoing default VC on a packet-by-packet basis according to level information (destination address and routing table). Moreover, incoming and outgoing dedicated VCs are concatenated by CSRs that forward packets cell by cell 8. Concatenation of a number of dedicated VCs from a source host (or router) to a destination host (or router) is called an bypass-pipe. It carries packets belonging to a single communication between the end points (flow), and is set up by using a bypass-pipe control protocol called Flow Attribute Notification Protocol (FANP); nodes that understand FANP are said to be bypass-capable. CSRs are bypass-capable and can be either end points or intermediate nodes of bypass-pipes, while bypass-capable conventional routers and hosts may be end points only. 8 Notice that this never applies to default VCs. 7

9 Non-bypass-capable station Traditional router CSR Bypass-capable station network network CSR Higher Layers Routing AAL5 Default VC Dedicated VC AAL5 Switching AAL5 PHY PHY PHY Figure 7: CSRs deployment scenario and architecture. A bypass-capable host or router decides whether to send a packet through a default VC or to set up a bypasspipe according to a locally defined policy (level of traffic towards a certain destination, a TCP connection being opened, a reservation request having been issued). Non-bypass-capable nodes can interoperate with CSRs by sending them datagrams over default VCs. A CSR which receives an packet from a default VC decides whether to forward it over a default VC, or to set up a bypass-pipe to the ultimate destination (or to the bypass-capable router nearest to the destination and reachable through a path composed only of CSRs). Dedicated VCs can be either dynamically set up upon creation of a bypass-pipe, picked from a bundle of preestablished VCs kept between a couple of CSRs, or extracted from a (semi-)permanent virtual path. Conventional over CSRs first appeared as part of the conventional over routing model proposed in a draft document [21]; this model had been declared of non primary interest by the over () Working Group and it is being worked on by the ad hoc COnventionaL (COL) Working Group. Hosts are allowed to communicate directly only with hosts in the same LIS; broadcast-based mechanisms are not modified for adaptation to the non-broadcast service; instead, switches are required to provide a broadcast connectionless service. Moreover, classical routers are replaced by CSRs. switches could provide broadcast connectionless service by working similarly to transparent bridges; an AAL carrying MAC addresses in the first cell is needed. Current equipment cannot support such a service; the Conventional over model does not require a general-purpose broadcast data delivery service, but just a service for carrying ARP requests: this can be provided fairly easily, since it operates just inside a LIS (and a well-designed network does not have very large LISs). After a host has resolved the address of the next hop, it can set up a VC to it and use the conventional unicast connection-oriented service to send packets to the destination. 7.3 Comparison Multilayer switching approaches can be categorized as flow-based approaches, since level switching is preferred to level forwarding depending on the characteristics of the data flows. Instead, Tag switching and ARIS can be regarded as topology-based approaches because VCs exploitation is related to the topology of the network and the routes chosen by routers for delivering packets. Flow-based approaches can guarantee like QoS to a traffic flow since it can receive a dedicated VC which is handled (i.e., switched) at the level. On the contrary, topology based approaches must be modified in order to support QoS guarantees because they carry traffic from different applications over the same VC. QoS could be required by applications through usual mechanisms like, for example, RSVP. Nevertheless, the non trivial problem of mapping application requirements to reservation of physical resources has to be addressed. All the approaches support multicast communications by associating to either a multicast packet flow (flowbased approaches) or an multicast routing tree (topology-based approaches) a point-to-multipoint VC created through the mechanisms characteristic of each approach. 8

10 Deployment of multilayer routing is advantageous with any over model, and even with other network layer protocols. When employed within the classical over model, multilayer switches can forward packets cell-by-cell across the boundaries of LISs. In an internetwork operating NHRP, there may be subnetworks between which level internetworking is not allowed (i.e., VCs cannot be set up between end systems connected to different subnetworks) owing to incompatibility (e.g., subnetworks run different signaling protocols) or for the sake of security. Since multilayer routers use ad hoc protocols to setup VCs (instead of standard signaling), they can be used as egress routers in such a context, thus allowing packets to be forwarded cell-by-cell across subnet borders. Multilayer switching can be introduced gradually; some (egress) routers can first be upgraded without the need for hosts to be aware. Next, hosts can be enhanced to exploit subsidiary protocols coming with these approaches so as to get the best from multilayer switching. 8. The Integrated P-NNI model According to the Integrated P-NNI (I-PNNI) model [22], routers and switches deploy the same routing protocol, namely the I-P-NNI routing protocol, which is a backward-compatible extension of the P- NNI protocol enhanced to carry level reachability information 9. Routers and switches exchange neighbor greetings packets (P-NNI Hello Packets) and messages carrying topology information, i.e. on the links between a switch and a router the P-NNI protocol is used instead of the UNI protocol. While calculating paths for packets through networks, routers take into account level topological information; these routes are far more optimal than that calculated conventionally. routers are announced as non-transit nodes, i.e. nodes through which no other node is reachable. Call setup signaling messages are not forwarded to routers unless they are the endpoint of the VC required. switches do not need any modification to support the I-PNNI protocol; they do not understand level information carried by I-PNNI packets, but must store it. Thus, their storage capabilities must be greater than those required for operation in a conventional P-NNI environment. In a network operating NHRP, the I-PNNI enhances capabilities of an NHS by allowing it to find the best path for routing an NHRP request. In addition, since the I-PNNI protocol also carries level reachability information for destinations outside the subnet, the next hop egress router can be optimally chosen for external destinations. 9. Conclusions Internet is evolving to support the ever-growing number of users and more demanding applications. The Integrated Services Internet aims at providing services with the guaranteed QoS required by multimedia applications. One solution for their provision exploits high-speed SDH channels to increase the available bandwidth, and delegates to the routers the management of network resources through complex packet queuing schemes. Another solution is the deployment of, which is worthwhile for both the high bandwidth connections it provides and the services with assured QoS it implements. Two mechanisms are required to establish this solution: (1) the QoS required by applications must be mapped on the QoS provided by the underlying network, and (2) data transfer must be delegated, as far as possible, to switches (i.e., routers are to be used only when mandatory). The many models for deployment of in the Internet proposed by both IETF and Forum have been surveyed in this paper. Some envisage deployment of the routers operating over the network and exploiting its data delivery service to forward packets, but differ with regard to the way the next hop for forwarding a packet is chosen. Others propose a means of interoperating networks and networks, and are characterized by a deeper integration between routers and switches. Some of the proposed models are very complex. Even so, the interoperation of a connectionless protocol such as with a connection-oriented technology such as is still an open issue: on the one hand, if connections are managed dynamically, signaling delays significantly reduce performance; on the other hand, static deployment of VCs leads to poor exploitation of the very services provided by networks. 9 The I-PNNI model can be applied to any network layer protocol: work has been done for, ng, and CLNP. Moreover, the I-PNNI is a general purpose interior gateway protocol that can also be used also over non- networks. 9

11 10. References [1] S. Bradner and A. Mankin. The Recommendation for the Next Generation Protocol. RFC Internet Engineering Task Force. January [2] R. Braden, D. Clark e S. Shenker. Integrated Service in the Internet Architecture: an Overview. RFC Internet Engineering Task Force. July [3] R. Braden, L. Zhang, D. Estrin, S. Herzog e S. Jamin. Resource ReSerVation Protocol (RSVP). S. Bradner Ed. Work in progress: draft-ietf-rsvp-spec-14.ps. Internet Engineering Task Force. April [4] ITU-T. B-ISDN Protocol Reference Model. Recommendation I.320. Melbourne [5] M. Borden, E. Crawley, B. Davie, and S. Batsel. Integration of Real-time Services in an - Network Architecture. RFC Internet Engineering Task Force. August [6] H. L. Truong, W. W. Ellington, J.-Y. Le Boudec, A. X. Meier, and J. W. Pace. Lan Emulation on an Network. IEEE Communications Magazine. May Pages [7] The Forum. LAN emulation over - Version 1.0. Forum Technical Committee - LAN Emulation Sub-Working Group, January [8] The Forum. Private Network-Network Interface Specification Version 1.0 (PNNI 1.0). March [9] Y. Rekhter and D. Kandlur. Architecture Extensions for. Work in progress: draft-rekhter-ip-atmarchitecture-01.txt. Internet Engineering Task Force. July [10] J. Heinanen. Multiprotocol encapsulation over adaptation layer 5. RFC 1483, Internet Engineering Task Force. December [11] R. G. Cole, D. H. Shur e C. Villamizar. over : a framework document. RFC 1932, Internet Engineering Task Force. April [12] M. Laubach. Classical and ARP over. RFC Internet Engineering Task Force. January [13] D. Katz e D. Piscitello. NBMA next Hop Resolution Protocol (NHRP). Work in progress: draft-ietf-rolcnhrp-11.txt. Internet Engineering Task Force. March [14] Forum Technical Commitee. Multi-Protocol Over Version 1.0. Work in progress, STR- MPOA-MPOA-01.00, February [15] B. Fink. / Integrated Routing & Addressing (IRA) Model. Work in progress: draft-fink-ipatm-ira- 00.txt. March [16] D. Perkins and F. Liaw. Beyond Classical - Integrated and Architecture Overview. Work in progress: Forum September [17] Y. Rekhter et al. Cisco Systems Tag Switching Architecture Overview. RFC 2105, Network Working Group. February [18] A. Viswanathan, N. Feldman, R. Boivie, and R. Woundy. ARIS: Aggregate Route-Based Switching. Work in progress: draft-viswanathan-aris-overview-00.txt. March [19] P. Newman et al. Transmission of Flow Labelled v4 on Data Links Ipsilon Version 1.0. RFC 1954, Network Working Group. May [20] Y. Katsube, K. Nagami, and H. Esaki. Toshiba s Router Architecture Extensions for : Overview. RFC 2098, Internet Engineering Task Force. February [21] M. Ohta, H. Esaki, and K. Nagami. Conventional over. Work in progress: draft-ohta--overatm-02.txt. March [22] J. Jeffords. Integrated PNNI (I-PNNI) v1.0 Specification. Work in Progress. Forum R1. October