Towards a Logical Addressing and Routing Sublayer for Internet ...

Towards a Logical Addressing and Routing Sublayer for Internet Multicasting Jean-Jacques Pansiot * ([email protected]) Dominique Grad † ([email protected]) Stella Marc-Zwecker * ([email protected]) * Université Louis Pasteur, LSIIT and Computer Science Department, 7 rue René Descartes F67084 Strasbourg Cedex, France Phone: (33) 88 41 64 28 Fax: (33) 88 41 66 28 † Université Robert Schuman, IUT Strasbourg-Sud, Département d’Informatique 72, Rte du Rhin F67400 Illkirch-Graffenstaden, France

ABSTRACT We consider the internetwork layer for multicast communication and show that addressing and routing problems differ substantially from the case of point to point communications. In particular internetwork group addresses are highly dynamic objects that are created by applications, and multicast routing must handle scalability and security. We show that these new problems could best be handled in a new sublayer above the Internet sublayer called Logical Addressing and Routing. We then give some hints on how such an architecture could work, in particular for dynamic group address allocation, incremental diffusion tree construction and routing control. I Introduction Today's large networks, and in particular the Internet, are based on an architecture designed for point-to-point communications. Network addresses are basically geographical location, or routes towards such location. Routing, though dynamic, is essentially concerned with finding the best route, given (static) routing policies and a (static) configuration with possible components failures. Objects (addresses, routes) handled in the Internet layer, say IP, are thus mainly static and independent from the user applications. The first layer that depends on applications is the Transport layer, where for example a connection is dynamically created by a calling user process, say telnet. Moreover, except for Application gateways, the Transport layer is involved only at the two endpoints of the communication. - 1 -

As we will show, multipoint communications (or group communications) are very different. In particular, a group may be dynamically created by the Application layer, and its address must be handled at intermediate nodes, for example for the creation of a multicast tree. We propose to define a sublayer handling logical addressing and routing for best effort delivery of multicast datagrams sent to a (logical) group address. This sublayer makes use of the normal unicast Internet sublayer, e.g. IP, IPng or CLNP, and associated routing protocols. In section II we give some basic definitions and the main differences between unicast and multicast at the Internet layer. In section III we propose our two layered approach and give some indications on how it could work. In section IV we conclude on some benefits and problems with this architecture. II

Point to Point and Multipoint communications in the Internet layer. A point to point (or unicast) communication involves only two hosts, and each packet is sent

to only one destination. In a multicast (or multipoint, or group) communication, a packet may be sent to a group of destinations. This means that the packet must be duplicated somewhere. In this paper we are concerned with the Internet layer, and our examples will be taken mainly from the TCP/IP world and its multicast extensions. We think that the situation would be basically the same in other internetwork architectures. The current approach is to deal with internetwork multicasting at the same level as the usual unicasting. The basic idea is to construct a tree such that the sender is a node of the tree, and the packet is forwarded along the tree until it reaches all nodes, including all destinations. Current research includes algorithms to build efficiently such trees while optimizing some parameters such as their diameter. Also for a group with several sources, one may define one tree per source as in DVMRP [RFC1075] or only one tree for all sources as in CBT [BFC93]. We will look in turn at addressing, routing, duplication and switching. II.1

Addressing Network addressing in a unicast communication is based on hierarchical addresses pointing

to a geographical location, or sometimes on routes towards such a location. The correspondence - 2 -

between a host and a Network address is static, except for mobiles which are not directly handled in the current architecture (see VIP [TUS94]). Moreover, because of the hierarchical structure of addresses, intermediate entities need not to know individual addresses, but rather subnetworks, networks. These (sub) network addresses are even more static than host ones, and are basically allocated "by hand". Unicity of addresses is rather easy to get. A group address, for example a class D IP address for IP multicast [RFC1112], does not correspond to a geographical location. Correspondence between a host and a group address is dynamic, it is established while this host is a member of this group. Moreover the lifetime of a group address may itself be limited, because groups may be dynamically created and destroyed. Clearly there must be an automatic system to allocate Network group addresses if computer supported cooperative work [BB91] is to be widely deployed. Moreover global (flat) group addresses, such as class D addresses, are difficult to allocate in a distributed manner. Finally, one may observe that a unicast Network address concerns a physical host where a multicast address is a logical address corresponding to some instance of application. II.2

Routing By routing we mean here informations necessary to route a packet toward its destination(s),

and the protocols to get such informations. In the unicast case, routing informations concern individual hosts, or more generally subnets or nets. Because of the rapidly increasing number of nets, higher levels of aggregation have been defined, such as in CIDR [RFC1519]. Therefore, in a routing table, the further is a net, the lesser information has to be kept in the table. Routing tables are generally dynamically constructed using routing protocols. However this evolution is rather slow and is due to: • components failures or recovery, hopefully not so frequent at least on backbones, • modification of network architecture such as new links, • connection of new networks. It is shown in [Chi93] that, except for failures of component at the periphery of the internet, routing - 3 -

tables are quite stable. Moreover if we consider interdomain routing, propagation of routing information is strictly filtered by the routing policy of each routing domain. To summarize, routing informations are stable, depend on routing policy and geography, and are independent of user application currently running. In the multicast case, routing information is associated to group addresses, which are basically independent of location, and possibly to the source address. The principle of aggregation seems hard to use. If group communications such as those needed for cooperative work are to be widely used, the number of required group addresses is potentially unlimited, since any set of users in the Internet may form a group at a given time. In fact the size of these routing tables depends not only on the number of groups whose communication must get through a given router, but also on the number of sources in the group. This is the case in particular, when one multicast tree is defined for each source. Moreover, these routing tables must evolve fast, because their contents depend on the creation or deletion of groups, and worse, on insertion and deletion of group members. The lifetime of a group might be measured in hours for example, but in large groups, membership could change as fast as once every minute. This means that routing information must change much more often than in the unicast case. Another difficulty with group addresses, for highly open and dynamic groups, is to dynamically define routing policy for them. To summarize, multicast routing tables are highly dynamic, may reach a size basically independent of the internet, and depend on user applications. One would expect for example that the size of routing tables would grow at peak hours in the same fashion as traffic. Therefore, scalability is an important eschew for multicast routing. As a last remark we observe that multicast routing may use information from unicast routing protocols. Some proposed Internet multicast protocols use specific unicast routing protocols such as MOSPF [RFC1584], others are independent of unicast routing protocol such as PIM [DEF94]. II.3

Switching and Duplication By switching we mean the operations performed on a received datagram before it is delivered. - 4 -

In the unicast case, switching consists mainly in a lookup into the routing table, the lookup key being the destination address, plus possibly other header fields such as Type of Service and Source Route. The packet is sent only once. In the multicast case, the table lookup must generally make use of the sender address, at least in groups with multiple senders. The packet may then be duplicated. This is because a multicast packet with N destinations must be duplicated at some points in the network to generate N copies. It should be noted that duplication can be done in two ways: • explicit duplication by a node in the Network layer. This is the only solution when the underlying service at the Link level is only point to point, • implicit duplication by the medium in the Link or MAC layer. For example over Ethernet, the Network layer has only to pass a single copy of the packet, with a multicast destination. One copy of the packet will be read simultaneously by several destinations. We see that duplication is the main difference between unicast and multicast.

But

duplication is a serious security hole. This is well known for the implicit duplication at the MAC layer. Anybody can spy on data sent on an Ethernet network. Uncontrolled multicast routing would just make the whole Internet one big Ethernet network as far as security is concerned. Because of this it should be impossible for a new duplication to be done in some node without knowledge of upper layers. Since duplication in a node is just a consequence of routing information, this means that dynamic routing of a group should be controlled by upper layers. This is totally different from the unicast case. II.4

Conclusion From the points discussed above, we may draw some conclusions:

• multicast deals with dynamic objects created by upper layers and users, • multicast puts big constraints on a router in terms of scalability, frequency of routing updates, and security, • these constraints should be imposed only on routers where they cannot be avoided, that is on routers where duplication takes place, - 5 -

• multicast may make use of unicast routing for constructing routing tables. From these remarks we propose that multicasting be handled in a separate sublayer above the usual (unicast) Internet layer. This new Logical Addressing and Routing (LAR) layer would allow to separate problems of different nature and to handle multicast for a group only where it is unavoidable, that is where duplication takes place. In the next section we present our proposition for a two-layered approach. III

The two-layered approach

III.1

General principles

III.1.1 The LAR sublayer We propose the insertion of a Logical Addressing and Routing (LAR) sublayer, between the Internet sublayer (that will be more generally called Network layer in the following sections) and the Transport layer. This new sublayer is the upper one that can be present at intermediate nodes (excepting Application gateways), while being the lower one that handles informations of Application dependent semantics. In particular it allows to identify the members of a group independently of their location (logical addressing), and to convey information between them (routing). The LAR sublayer’s message delivery service is supplied to a group of entities that can be widely spread among a networks interconnection. This service can be seen as connectionoriented (members must join the group in an initial phase and leave it in a final phase), although it provides only a best effort message delivery, without flow control or error control. III.1.2 Logical addressing principle We define the LAR addressing by the following characteristics: (i) LAR addresses provide (logical) identification of dynamic Application objects (i.e groups), and are totally independent of any geographical location, by opposition to Network layer addresses [PR90], [RFC791]. For example logical group addresses could be derived from an identifier of the organization to which the group's creator belongs. (ii) Logical addresses are hierarchically allocated to easily guarantee their uniqueness. Let us remind that flat allocation of IP multicast addresses does not provide this property. - 6 -

(iii) The LAR sublayer allows nodes to hierarchize address analysis. That is due to the fact that only Network PDUs (NPDUs) whose Network destination address explicitly identifies the LAR entity of a given node will reach the LAR sublayer at this node. Therefore only nodes that play an active part in multicast operation for a given group will be addressed at Network level and will analyze LAR level (group) informations. An NPDU that encapsulates a LAR PDU then transparently crosses all the intermediate nodes that are not identified at LAR level by Network addresses, i.e no duplicating nodes: these intermediate nodes act in fact as passive relays and do not have any knowledge about the group (see Fig. 1). This principle can be advantageously compared to IP multicast, where every intermediate node that is reached by a Network PDU must analyze its IP multicast destination address, even if it does not take an active part in multicast operation (no duplication). Consequently it has to maintain entries to process the multicast address of each group that passes through it. The selection of the nodes that are relevant for a given group (called LAR nodes), is allowed by address conversion. This mechanism performs a mapping between a LAR address and the associated Network addresses. It allows a LAR entity to decide after previous analysis of the LAR address, if it has to deliver the LAR PDU to the upper layer (member node) and/or it has to forward it to other LAR entities (duplicating node). The Network destination addresses that are mapped from the LAR address identify in fact those next LAR entities. Note that the same conversion mechanism is executed by IP routers to perform the mapping between Network and Link or MAC addresses. Remark: We say "conversion" because at each intermediate duplicating LAR node, source and destination Network addresses are changed (see Fig. 1). III.1.3 LAR Architecture In a group communication, copies of a packet are propagated towards members by successive duplications made by strategic nodes. Those duplicating nodes will be chosen in such a way that many copies of one packet will not be sent on a same link. Fig. 1 depicts an example of our architecture where NSDU (@NS, @ND, LAR PDU) represents a Network SDU, @NS and - 7 -

@ND are the source and destination Network addresses that identify respectively SDU’s sending and receiving LAR entities. NSDU1 is sent from LAR node S and received by LAR node A, that makes a duplication, and sends NSDU2 to LAR node D1 and NSDU3 to LAR node D2.

DUPLICATING LAR NODE

INTERMEDIATE NODE

INTERMEDIATE NODE

routing

routing

B

C

MEMBER LAR NODE

upper layers duplication LAR sublayer (2)

(3)

(1) Network sublayer lower layers

from S

A

to D1

to D2

D2

(1) NSDU1 (@NS, @NA, LAR PDU) (2) NSDU2 (@NA, @ND1, LAR PDU) (3) NSDU3 (@NA, @ND2, LAR PDU)

Fig. 1: LAR Framework In our architecture, we choose to build a unique center-based tree instead of source-specific trees. To build the tree is to select duplicating nodes and members as the tree vertices. A tree edge such as (A,D2) is supported by the Network layer as a point to point communication between vertices. Intermediate nodes (like B and C) do not activate the LAR sublayer for this group. Only members such as D2 deliver SDUs to upper layers. III.1.4 Duplication Duplicating nodes carry out duplications by sending copies to individual nodes, and/or by sending a single copy to a set of destinations, via a shared broadcast medium (called multicast environment in the sequel). Such an environment could be a LAN,

providing a Link level

broadcast service, or an Autonomous System, using a Network layer multicast protocol [BFC93] [DEF94] [RFC1075] [RFC1584]. This routing protocol could multicast easily, and only the border nodes would have to implement the LAR sublayer. Fig. 2 illustrates the different types of duplication, where grey nodes belong to LAR tree and white ones do not:

- 8 -

AS

LAN

Duplication Intermediate Node

Duplicating Node

Duplicating Node & Member

Member

Fig. 2 : Tree Duplication Points Remark: Nodes with degree 2 in classical multicast trees, do not have to belong to the LAR tree if they do not have a duplication function. Nevertheless, only nodes that are members or with a neighboring multicast environment should have a degree ≤ 2 in the LAR tree. We will make use of duplications on multicast environment when possible (see Fig. 3): medium A is used for duplication between three nodes, but medium B remain as a point to point edge, because it is used for communication between only two LAR nodes.

A B

Classical Multicast Tree

LAR Tree

Duplicating Node and/or Member Duplication by Multicast Environment

Relay Node

Fig. 3: Multicast Distribution Trees - 9 -

III.2. LAR sublayer addressing We first describe how the LAR group addresses are managed, and then we show the relationship between LAR addresses and adjacent layers addresses. III.2.1 LAR addresses definition Since we consider the context of group communications, we present the management of logical addresses within a group. III.2.1.1 Obtaining logical addresses We suppose that groups are identified by logical hierarchized names, similar to DNS (Domain Name Service [RFC1034]) ones (e.g. "perf.net.u-strasbg.fr" could denote a performance analysis working group, organized by the network research team of Strasbourg university). The association between a group name and the corresponding unique LAR address, can be performed by a DNS-like hierarchized directory, that we call LAR directory. The additional difficulty for this directory lies in the need to provide dynamic address allocation. This mechanism must be automated and actually faster than DNS's, that generally relies on manual modifications. Note that address deallocation must also be automatic, but with less time constraints. To allow LAR communications we must define, not only group destination LAR addresses (noted @LD), but also source LAR addresses (noted @LS), so that the originator of a LAR message can be identified. The identification of a message sender must be done indeed at LAR level, because the Network address of the sender is lost after the traversal of the next LAR node (see conversion mechanism in Fig. 1). The source LAR address (@LS) can be used, if needed, to individually identify the message originator. Therefore individual LAR addresses could be either: • directly derived from the originator's Network address (not good for layer independence), • or derived from the group logical address (@LD), for example by adding a selector, • or independently assigned as suggested for Universal Transport Addresses in [RFC1705]. Remark: Every LAR node should also have an individual LAR address to perform layer management, in the same way as Internet routers have their own IP addresses. - 10 -

III.2.1.2 Group creation The group manager (in the sequel, we will assume that the creator is also the manager of the group), sends a request to LAR directory with the proposed name. The Directory responds with the LAR address created for the group, as well as the manager's individual LAR address. After this, the manager can publish the group name in a group directory similar to the Session Directory (sd) used in the Mbone [Eri94]. III.2.1.3 Joining a group Any candidate to join a group must send a request to the manager, whose address has been obtained from the the group directory. The manager then executes a group access control phase for this potential new member and sends a failure or success response. In case of success, the manager starts the execution of a distributed algorithm for adding the new member to the LAR tree (see III.4.1). Following this step, the manager sends to the new member: • the group's LAR address, • the new member's individual LAR address, • the addressing information needed by the new member to join the LAR tree. This information obtained during the previous tree modification process, consists in the Network address(es) of the LAR tree node(s) that is (are) going to be the direct neighbor(s) of the new member. Therefore the new member will be able to perform conversion between group's LAR address and Network address(es) of the node(s) that attach him to the LAR tree. Remark: Case of open groups The proposed architecture allows to take into consideration the case when the originator of a packet addressed to a group does not itself belong to the group. This external sender must first join the group manager (using the groups directory), by sending him a request. The manager then performs an "open" group access control phase, and informs the external candidate on the failure or success of his request. In case of success, the manager sends to the external member: • the group's LAR address, • the external member's LAR address: this can be a constant LAR address designating any external - 11 -

sender, in case of anonymous identification. Otherwise it is defined as in III.2.1.1, • the Network address of the LAR tree node of attachment. Note that, in opposition to a member’s attachment, the aforementioned attachment is unidirectional and allows an external member to send messages to the group, but not to receive messages from the group, because the external member's address does not figure in its attachment node's routing table. III.2.1.4 Leaving a group When any member different from the manager leaves the group, this is followed by his LAR individual address deallocation. When the manager, that we suppose to be the last member, leaves the group, this is followed by both his LAR individual address and the group's LAR address and name deallocation. This leads to the modification of both the LAR and the groups directories. Remark: When the LAR protocol detects the silent failure of a member, it must undertake the member's LAR address restitution. III.2.2 Relationship with Network and Transport addresses We first present the relationship between LAR addresses and adjacent layers addresses. Then we show that the concept of multicast addresses at Network level keeps its interest, and we suggest a new hierarchized structure for such addresses. III.2.2.1 Building of adjacent layer addresses LAR addresses are not built from Network addresses, since a logical group (or member) identifier is independent of any location. The link between LAR and Network addresses for a group member is computed dynamically during the group joining phase. On the other hand, the LAR address can serve as a basis for the hierarchical building of a Transport address, by adding a selector [PR90]. For instance, TCP port numbers constitute selectors that are added to IP addresses. III.2.2.2 Multicast Network addresses As shown in section III.1.4, LAR sublayer must be able to send a single packet to a set of destinations over a multicast environment. Consequently, multicast addresses are needed at - 12 -

Network level. That means that the conversion of a LAR destination address into Network addresses must supply a unique multicast Network address, instead of a set of unicast Network addresses that would lead to redundancy. However, in contrast to current IP multicast addresses, it would be better to have hierarchical Network multicast addresses. We can observe indeed that in the current IP addressing scheme, unicast and broadcast addresses are hierarchical. Moreover one may send a broadcast in a (sub)network, even a distant one: this is sometimes called a directed broadcast. Current flat IP multicast addresses do not allow such mechanism. Therefore, in the case of a (sub)network covered by an implicit diffusion medium, a hierarchical multicast Network addressing scheme would allow either: • to limit the spread of diffusion within a (sub)network, • to avoid unnecessary duplications at the Link level, • to provide a directed multicast mechanism. Note that the multicast semantics of such addresses need not to be known outside of the identified network, since only the network's prefix is analyzed outside of it. We may observe that such a multicast addressing at Network level would only concern a localized set of machines sharing a common diffusion medium: that is perfectly suited to the geographic semantics of Network addresses. Remark: To use such type of addresses, we need to have a way to dynamically allocate multicast Network addresses within a LAN. [Hay93] describes such a mechanism for the dynamic allocation of MAC addresses. III.3

Switching For a given group, only the duplicating nodes and/or members maintain an entry in their

LAR sublayer routing table. Each logical address matches a tree neighbor descriptor list. @LD1 → @LD2 → ......

(A10, A11, A12, A1 3, A14) (A20, A21, A22) ...............

Each descriptor AIj indicates a Network address value, if this address is unicast or multicast and if it - 13 -

identifies a passive member (receiver only), an external member (sender only) or a general group member (sender and receiver). Each address value can belong to one of three types: (i)

the reserved indicator @ME, if the node itself is a member,

(ii)

a unicast Network address identifying one neighbor in the tree,

(iii)

a multicast Network address for a multicast environment.

For instance, in a node which is only a member (a tree leaf), the list is composed of two addresses: the indicator @ME and the Network address of its tree attachment point (see E in Fig. 4) E

F M

B

A in B in C in E

@LD @LD @LD

→ → →

C

D

(@NA (ii), @NM (iii), @NC (ii) ) (@NB (ii), @ME (i), @ND (ii) ) (@ME (i), @NM (iii) )

Fig. 4: LAR Routing Table entries for group G On a tree node, the switching process has to forward a datagram copy along each contiguous edge except the incoming one. To do this, all multicast algorithms analyze destination and source addresses. The LAR switching algorithm has to distinguish a unicast from a multicast destination Network address to identify the incoming edge (see switching algorithm below): Let {@LD} be the address list of the group identified by @LD On reception of ( @NS, @ND, @LS, @LD, msg ) IF @ND is an unicast adress THEN // sender is a neighbour in the tree // sender source address @NS is in {@LD} IncomingEdge = @NS ELSE // received by a contiguous multicast environment // multicast destination address @ND is in {@LD} IncomingEdge = @ND ENDIF RecipientList = { {@LD} \ IncomingEdge } FOR each @NDest in RecipientList //sending copy or delivering to upper layer DO IF @NDest is @ME THEN // to upper layer (member) Delivering of ( @LS, @LD, msg ) to upper layer ELSE // towards Network layer (duplication) Sending of ( My@N, @NDest, @LS, @LD, msg ) ENDIF DONE

- 14 -

For instance, this algorithm works as follows with network of Fig. 4: On reception of ( @NA, @NB, @LS, @LD, msg ) in B @NB is unicast IncomingEdge = @NA RecipientList = {@LG} \ @NA = { @NM, @NC } → Sending of ( @NB, @NM, @LS, @LD, msg ) → Sending of ( @NB, @NC, @LS, @LD, msg ) On reception of ( @NB, @NC, @LS, @LD, msg ) in C @NC is unicast IncomingEdge = @NB RecipientList = {@LD} \ @NB = { @ME, @ND } → Delivering of ( @LS, @LD, msg ) to the upper layer → Sending of ( @NC, @ND, @LS, @LG, msg ) On reception of ( @NB, @NM, @LS, @LD, msg ) in E @NM is multicast IncomingEdge = @NM RecipientList = {@LD} \ @NM = { @ME } → Delivering of ( @LS, @LD, msg ) to the upper layer

III.4

Routing and tree evolution Nodes which will undergo a modification are successively determined according to the

evolution of group membership. A new member needs one more duplication in the multicast tree. The member insertion can be done in four different ways (see Fig. 5): • adjunction of an edge contiguous to an existing node (A). • adjunction of a duplicating node of degree 3 by splitting an existing edge into two parts (B). • adjunction of three nodes contiguous to a multicast environment, which then becomes duplicating (C). • without any modification if the new member is connected to a multicast environment already duplicating in the tree (D) (or if the new member is already a duplicating node). B

D nodes added to LAR tree

A

nodes belonging initially to LAR tree

nodes not belonging to LAR tree

C

Fig. 5 : Adjunction of A,B,C,D to a LAR Tree. A member disconnection yields a symetrical modification of the tree.

- 15 -

III.4.1 Tree construction We are currently working on a simple incremental algorithm based on the center of the tree. Recall that the eccentricity of a node is the distance to the furthest node, and the center is the node with minimal eccentricity. The algorithm inserts (according to one of the four situations of Fig. 5) new edges and/or duplicating LAR nodes, where the route from the center to the new node departs from a tree node or edge. After each modification, the new

center can be distributively

recomputed. III.4.2 Robustness We should not find failures on tree edges because intermediate node or link failures are handled by the Network layer. We could use well known « keep alive » mechanism to detect member or duplicating node failures as in EGP [RFC904]. A mechanism common to all groups, could establish a set of neighbors and send a Hello message to each of them. An edge shared by many LAR trees would need only one Hello message. When a neighbor fails, all trees containing this node should be updated. III.4.3 Failure and tree reconstruction In case of failure of a member without a duplication function, the neighbor node should delete the tree edge which connects it to the member. It should also inform the manager to ensure the deallocation of the logical member’s address (see II.2.1.4). A node detecting a duplicating node failure would notify the manager, who could either respond by giving the address of another neighbor, or ask for tree reconstruction. Remark: Following such a failure, the manager could be flooded by the notifications. Nevertheless, the number of these messages cannot exceed the node degree which should be limited by the number of node interfaces. The incremental evolution of the tree requires the periodic follow-up of the tree weight and diameter by the manager. The manager can ask a complete tree reconstruction that could be performed for instance by the computation of the shortest-path tree rooted on the tree center.

- 16 -

Remark 1: Case of non-LAR nodes: During tree construction, a LAR node has to reach the next LAR node on the route to a given node. This address cannot be supplied by the Network layer in case of presence of non-LAR nodes. Each LAR node could resolve this problem by two different ways: statically by keeping the addresses of all its LAR neighbors, or dynamically by successively querying the intermediate nodes on the route to some node. An address list of these nodes should be supplied by the Network layer. Remark 2: Problems related to a multicast environment: In a multicast environment, all contiguous LAR nodes should cooperate. A designated node will be in charge of maintaining for each group a list of members and duplicating nodes [Dee91]. This information will be used in case of node failure.

III.5

Network service interface and primitives The Network service interface should indicate whether an address is unicast or multicast. It

should also deliver source and destination Network addresses (needed by switching) with each LAR message. It should finally indicate whether two nodes are in the same multicast environment or not. The Network service should provide: • a Network reserved address AllLarNodes; this address allows to reach all LAR nodes including those not activated for a given group, • a Network multicast address dynamically associated to each LAR address in a multicast environment (see III.2.2.2), • the Network address of the next hop towards a given node and the distance to any node. This information allows tree construction (see III.4.1), • a route (address list) towards any node, only in case of non-LAR nodes presence.

- 17 -

IV Benefits and problems with a two-layered architecture Our proposition can be summarized in two main points: create a specific sublayer to handle Logical Addressing and Routing, and use this layer only where necessary.

IV.1 Separation into two sublayers We have seen that multicast addresses are very different in nature from unicast ones. Our architecture allows to separate these two types of objects, and to leave the Network layer almost unchanged. The main goal of the Network layer remains the computation of good routes towards basically static addresses, in the presence of potential link failures. This sublayer remains independent of users and applications. The main goal of the LAR sublayer is to dynamically associate group members to dynamically allocated group addresses, while enforcing group membership policies and computing a good multicast tree. The independence of these two (sub) layers should allow the corresponding routing protocols to be independent, multicast routing being computed on top of unicast routing. In this aspect, it can be seen as a generalization of tunneling. We believe that the LAR sublayer will be useful not only for multicasting, but also each time logical addresses are necessary. We can mention a few of them: • communication with mobiles, for example the protocol VIP [TUS94] uses a separate virtual addressing sublayer, • anycasting, [RFC1546] where the problem is to reach a service provider using a generic logical address, • conversion when different addressing schemes or protocols are used at the internetwork layer. This last problem will be increasingly important with the future cohabitation of IP, IPng and CLNP. The LAR sublayer would allow to construct LAR-level routers in the same way as Network layer routers are currently used, making address and header translation between heterogeneous Network layers. This means that the LAR sublayer could be used in normal point-to-point communication. It

- 18 -

can be seen as a drawback since this calls for more header overhead. However it is already suggested that the Transport layer should be modified to include Universal Transport Addresses [RFC1705]. The LAR sublayer would be one way to implement these addresses.

IV.2 Presence of the LAR sublayer only where necessary This feature has at least three benefits, in terms of resources, control and applicability. IV.2.1 Resources Obviously, for a given group, the LAR sublayer will need to be activated only at duplication point, saving resources at intermediate points where no duplication takes place. This saving depends on the group structure. We can see our LAR tree as a tree where edges are in fact point to point routes, and each edge is either a single node or a (network layer) multicast cloud. The benefits are readily apparent if the average length of point to point routes is greater than one. To illustrate this point, we constructed a classical shortest-path tree interconnecting the maildrops of 19 persons, working in the same project (in fact members of the editorial board of a journal). This group could represent what a group supporting cooperative work could be. We got the following results: 19 nodes for members (leaves), 86 internal nodes with degree 2 (intermediate nodes), 13 internal nodes with degree at least 3 (duplicating nodes). Therefore among the 99 internal nodes, about 86% could get rid of routing information concerning this group. Of course this is only one example, and we plan to do some more systematic measures on this type of groups that may become more and more common. IV.2.2 Control Since duplication points are potential security holes, it is better to have as few as possible of them. In our proposal, one could say that it is the tree that goes towards the new member, not the way around, because an external node should not modify by itself the routing tables of a LAR tree node. Moreover, the algorithm to construct the tree could allow duplication points only in some routing domains known for their level of security. As a special case, duplication could be allowed only on domains containing members for example. Note that control must also be considered from - 19 -

the point of view of transit routing domain policies. One could imagine that some routing domain would not allow to have duplication points for some groups even if point to point communication of some members are allowed. To see this consider the following situation: - group G consists of members A, B and C - routing domain D allows transit routes from A to B but not from A to C. If a duplication point for G is installed in D, then communications from A to C could be sent using G, and thus go through D, in opposition to the unicast routing policy of D. IV.2.3 Applicability Since a general multicast protocol is not yet available, it will be a long time before all routers implement a common Network layer multicast protocol. This is the problem currently solved by tunneling in the Mbone. Things will be even worse, since at the same time the unicast Network layer will change with the implementation of IPng. It seems easier to separate evolution of the unicast and multicast problems at the Internet layer. Moreover as already mentioned, the LAR sublayer need not to be implement on all routers, and may play a conversion role, making a transition phase simpler.

IV.3 Remaining problems and perspectives The main problems we are now considering are: • incremental construction of a good multicast tree using only information given by the Network layer, • good recovery algorithms in case of a LAR node failure, • a dynamic directory for allocation of logical addresses, and local multicast Network addresses inside a domain, • recovery in case of failure from the group manager. More generally a study of group structure and dynamics is also necessary.

- 20 -

REFERENCES

BB91

Studies in Computer Supported Cooperative Work: Theory, Practice and Design, Eds. J.M. Bowers and S.D. Benford, Elsevier, 1991

BFC93

T. Ballardie, P.Francis, J.Crowcroft, Core Based Trees (CBT): An Architecture for scalable Inter-domain Multicast Routing, SIGCOMM'93, Ithaca, N.Y., USA, Sept. 93

Chi93

B. Chinoy, Dynamics of Internet Routing Information, SIGCOMM 93, Ithaca USA, Sept.93, p 45-52

Dee91

S. Deering, Multicast Routing in a Datagram Internetwork, PhD University, California, U.S.A., 1991

DEF94

S. Deering, D. Estrin, D. Farinacci, Van jacobson, C.G. Liu, L. Wei Protocol Independent Multicast (PIM): Motivation and Architecture, Internet Draft, draft-ietfidmr-pim-arch-01.ps, Oct. 94, 19 p.

Eri94

H. Eriksson, MBone: The Multicast Backbone, CACM, Vol 37 No 8, Sept. 93

Hay93

C. P. Hayden, Lan Addressing for Digital Video Data, Digital Technical Journal, Vol 5 No 2, Spring 93

PR90

A. Patel, V. Ryan, Introduction to Names, Addresses and Routes in an OSI Environment, Computer Communications, Vol 13 No 1, Feb. 90

RFC791

J. Postel, Internet Protocol, Sept.81, 45 p.

RFC904

D. Mills, Exterior Gateway Protocol Formal Specifications, Apr. 84, 30 p.

thesis,

Stanford

RFC1034 P. Mokapetris, Domain names - concepts and facilities, Nov. 87, 55 p. RFC1075 D. Waitzman, C. Partridge, S. Deering, Distance Vector Multicast Routing Protocol, Nov. 88, 24 p. RFC1112 S. Deering, Host extensions for IP multicasting, Aug. 89, 17 p. RFC1519 V. Fuller, T. Li, J. Yu, K. Varadhan, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy, Sept. 93, 24 p. RFC1546 C. Partridge, T. Mendez, W. Milliken, Host Anycasting Service, Nov. 93, 9 p. RFC1584 J. Moy, Multicast Extensions to OSPF, Mar. 94, 102 p. RFC1705 R. Carlson, D. Ficarella, Six Virtual Inches to the Left: The Problem with Ipng, Oct 94, 27 p. TUS94

F. Teraoka, K. Uehara, H. Sunahara, J. Murai, Mobility, CACM Vol 8 No 37, Aug. 94, p67-75.

- 21 -

VIP: A protocol Providing Host