Network Shape of IPConnect


This tries to describe some of the IP layer network shapes that IPConnect may want to present to each (end) customer. 



The simplest model is that  IPConnect presents as a LAN.  In this case all interfaces are in the same IP subnet (as denoted by the shaded box).

 

 In this case no IP addresses are actually present in IPConnect; all the IP addresses are in the customer router. (These may be allocated by IPConnect). All the IP addresses must be from the same subnet. The connection matrix is a complete mesh in order to preserve the LAN broadcast nature. So another view is as a number of point to point links.
Generalised slightly, these don't have to be in the same subnet anymore, nor form a complete mesh. However in his case an interior routing protocol, or series of static routes are required  to describe the adjacencies. [Note that each of these point to point links at the customer device may end up with a separate IP address due to driver limitations?]

Another model derived from the LANE model includes a new entity that supports LAN broadcast functionality by relaying all broadcast packets to other members of the ELAN. In contrast to LANE, this device is configured. (I am not sure how the customer routers respond to ATM ports in terms of whether they would send a packet to the IP subnet broadcast address, e.g. 130.102.76.255). In this scenario, there are some point to point VCs between routers, but additionally all the routers are connected to this broadcast relay. When broadcast traffic (or traffic between 2 routers using the 'unknown' relay) becomes  excessive, the telco would (recommend to)  implement an additional PVC. [This is a bit of new comms software that would need to be written. I am not sure where it would run, nor whether it would be supported by all customer routers].

Another implementation of LAN (or VLAN) is to introduce a number of layer 2 switches (like ethernet bridges) which are linked together by *Connect PVCs. This essentially expands the machine room hierarchical LAN to transcontinental dimension. It is probably still desirable to restrict the membership of this VLAN/subnet to just routers to reduce the  volume of broadcast traffic. An undesirable feature of such a setup for implementation by IP connect is that because of the flat address space of the VLAN that in order to avoid forwarding loops between the switches, they form themselves into a spanning tree. The consequence of this is that if some sites having a traffic dispersion that would require a partial mesh, would be formed into a tree. The redundant link would only be used if the spanning tree protocol detected that one of the links had failed.

The next case introduces an IP router for the first time. This means that each interface presented by IPConnect has an IP address, and these would be addresses in a subnet shared with the customer LANS.  In practice these subnets may be "/30" or perhaps unnumbered  interfaces, since only the customer router and IPConnect 'router' have interfaces on the point-to-point circuit. (I say that because I presume the IPConnect router would not be supporting the dynamic IP/ATM (RFC1577) nor LANE. The internal 'bus' of this router is a number of PVCs or PVCs with other routers. The 'router'  has to have routes configured in it to customer networks. These may include routes to an external internet, and may include alternate paths. These routes could be static, however these can lead to routing black holes. It would be far preferable for the 'router' to be able to participate in an internal routing protocol as a peer within the customer network's administrative domain.  In the single router view, adjacencies can I believe be assigned varying costs with both RIP and OSPF (though probably only a simple single metric with limited value range. RIP's cost is limited to 16 which is 'infinity'.)

Alternately, the internal structure of the routing network may be exposed. This may in fact be easier with existing routers. (In this case internal subnets used to implement the VPN would be visible since couldn't partition the administrative domain of the customers network).


All these are assumed to be private to a single customer. i.e. the IP addresses may be replicated in many customer VPNs, but the routing tables are totally independent.
The interconnectivity between the routers may be over *Connect managed links such as ATM, FR, Sonet or over a private or public internet backbone. In this case the links would be presumably incorporate a tunnelling protocol with QoS reserved via RSVP.
 
 

Also note that connectivity to external internets, including the global Internet, may be an additional service offered by the telco.  Other services may be DNS, web proxies, RADIUS, web servers etc.
 


If you have comments or suggestions, email me at d.horton@astracon.com.au