C2IG Meeting Minutes July 27, 1998

Present: Rob Bootsma, Nathan Freitas, Ben Humphrey, Elise Meyer, Larry Murdock, Rich Prohaska, Kevin Schmidt, and Jason Simpson

Research Group Connection Types

• Alexandria (Library) - Fast Ethernet (Engr I) - Fast Ethernet
• Arts - Fast Ethernet
• Comp Sci (Multimedia) - Fast Ethernet (Super Web) - Fast Ethernet
• HEP - Fast Ethernet
• ICESS - Fast Ethernet (via phone call)
• ITP - Fast Ethernet (via email)

Research Group Fiber

• Alexandria (Library) - OKAY
• Arts - OKAY
• Comp Sci (Multimedia) - Needs to run fiber (Super Web) - Needs to run fiber
• Alexandria (Engr I) - Needs to run fiber (EM: I'm assuming that this is the same as the Comp Sci groups)
• HEP - OKAY
• ICESS - OKAY (via phone call)

There was just a mention that this should be the responsibility of the research groups.

Connecting Switches and Routers

An additional scenario was proposed where a routing switch is still attached and routing to the FDDI backbone, but where it was possible for the switch to use port groupings to logically separate the ports so that some could use the FDDI, and some could have a switch access to the new CalREN-2 backbone. The important factor is that there is no signalling between the networks. This is indicated in the following diagram as #5. The group decided that this was technically possible, but we should recommend against it.

It was asked why you couldn't have scenario #1 (the router connection) also have a connection to both CalREN-2 and the FDDI. The answer was no, because routing is based on the destination address, not the source address, so there wasn't a way to stop the non-CalREN-2 subnets from using the CalREN-2 network for offcampus destinations.

All switches must do: spanning tree (802.1d), and they also should do IGMP snooping.

Why Switch Connections?

• Cheaper connection cost for the research group
• Some of the research groups that are going to initially attach to this network are currently connected to the FDDI via a shared departmental router. Since the general thought was that only research groups would initially attach to this network, it doesn't seem fair to make them purchase an additional router.

Switch Support

• Proprietary VLANs
• 802.1Q Standardized VLANs (802.1Q is currently in draft 10)
• A big old router

What do you get with VLANs?

• Broadcast containment
• Protocol containment
• VLAN switch interfaces are cheaper then router interfaces
• Switches can distinguish individual VLANs over trunk links and can multiplex and de-multiplex over a single physical link (see diagram below.)

None of the research groups wanted VLANs for anything more than a way to allow them to connect to the backbone via switches (i.e., provide inter-research group routing). This can also be provided by having the switch connections plug into a central router instead of a backbone switch. It was mentioned that VLANs might be a mechanism to provide Class of Service (CoS). This is not really a feature of VLANs. CoS is based on vendor-specific typing of priorities, and VLANs could be one of the criteria that packets are classified by for CoS.

What We Mean by Centralized Routing

External Routing (Rex)

• Must deal with OC-12 coming from off campus.
• Must be able to Map PVC's to unique logical interfaces for routing (At a minimum we think there will be at least two PVCs, vBNS and CalREN-2, in time there will probably also be one for UCNET.)
• Must do BGP
• Must have good performance
• May need VLANs (it depends on which Rex scenario is chosen.)

The possible options for Rex are:

1. The off-campus OC-12 PVCs are mapped to Rex, and Rex can map each PVC into a logical interface. There are two possible ways to do this (see diagram #1A and #1B below). In 1A) the SARing is only done by Rex, and ReX must be able to do VLANs. In 1B) SARing occurs between the two Rex interfaces and on the switch, but ReX doesn't need to do VLANs.
2. The off-campus OC-12 PVCs are mapped to the switch. Rex doesn't do VLANs. The switch breaks out the PVCs into separate physical interfaces and these are connected into separate physical interfaces on Rex (e.g. Rex has one i/f per research group and PVC). SARing is done by the switch. (See diagram #2 below).
3. The off-campus OC-12 PVCs are mapped to the switch. Rex does VLANs. The switch maps the PVCs into individual VLANs and the VLANs share one physical link connecting the switch to Rex. SARing is done by the switch. (See diagram #3 below.)

Inter-Research Group Routing (Rin)

• Talk to Rex
• Route between research groups
• OSPF
• RIP (No one really wanted to include RIP, but there was thought that we might not be able to exclude it at this point.)
• Adequate performance

This is currently being accomplished on the FDDI by everyone connecting to the backbone via routers.

The possible options for Rin are:

1. A routing switch
2. Using a separate router (Rin):
   • A. Rin supports VLANs, so multiple VLANs can use 1 physical interface (see diagram #2A below.)
   • B. Rin doesn't do VLANs, so each VLAN must have its own physical interface. The connection between Rin and the switch must be OC-12 ATM. (see diagram #2B below.)
3. If VLANs are not to be supported on the backbone, then Rin is a big router and switch connected research groups must connect to Rin instead of the backbone switch, and Rin must have an ATM connection to the backbone switch. (see diagram #3 below.)

Backbone Support

Discussion

That is the end of the meeting minutes. Now for some discussion that occurred after the meeting that we should think about.

The question was asked how the RFP-selected FSB fits into the Rex and Rin discussion and at the meeting I said that we had to find out a bit more about the FSB to know. Here's what we've determined so far.

1. We don't know of a router that does VLANs using the proprietary VLAN method used by the FSB.
2. The FSB can map PVCs into individual VLANs (we don't know the SARing performance for this, and we don't know if it is done in such a way that an offcampus external router can route the IP data.)
3. Regarding Rex:
   • If we can find a router that does support 802.1Q VLANs, then we can do Rex #1A or Rex #3.
   • If we can't find a router that does 802.1Q VLANs then we can only do Rex #1B or Rex #2.
4. Regarding Rin:
   • The FSB is not a routing switch, so option #1 is not possible.
   • If we can find a router that does support 802.1Q VLANs, then we can do Rin #2A.
   • If we can't find a router that does 802.1Q VLANs then we can only do Rin #3 or Rin #2B.
5. If we wanted to combine Rex and Rin functionality into one router we would want:
   • High performance (either OC-12 or GigE or both)
   • BGP
   • 802.1Q VLANs
6. To address Kevin Almeroth's multicast issues:
   • DVMRP (prefer PIM, also require tunnel & pruning support)
   • MBGP (Rex only)

We must have Rex functionality in order for CalREN-2 to work, but do we have to have Rin functionality?

1. We only have to have Rin functionality in order to allow research groups to connect to the backbone via switches. It should be cheaper for the campus as a whole to buy one Rin instead of having each research group buy their own routers, and also the maintenance and operation of a central Rin should be less. Supporting VLANs and centralized routing is also a good direction to go for a next generation backbone. BUT, the bottom line is that we might not be able to afford to pay for that functionality now out of the CalREN-2 budget. If that is the case, where do we go from here?
2. If we decide that we don't want to support switch connections by research groups then research groups connect with routers, and we would have Rex #1A without VLANs.

Back to Main CalREN-2 Page

EMM