X-Organisation: University College London, CS Dept. X-Fax: ++44 171 387 1397 To: idmr@cs.ucl.ac.uk cc: minutes@CNRI.Reston.Va.US Subject: IDMR Montreal minutes Date: Mon, 22 Jul 1996 16:58:48 +0100 Sender: minutes-request@ietf.CNRI.Reston.Va.US From: Tony Ballardie IDMR met in two sessions at the Montreal IETF; June 26 and 27. These minutes were compiled by Tony Ballardie and Bill Fenner. First session: Wednesday, June 26. Tony Ballardie started out the working group meeting with a document status report. The PIM and CBT specs are going through final revisions before being submitted for experimental. In addition, several MIBs are going to be reviewed by a member of the Network Management area and then submitted as experimental. Tony then presented an overview of a hierarchical multicast architecture, and accompanying transition strategy for evolving the MBONE from a mostly flat topology to one which comprises hierarchy. This work was a joint collaboration between Tony, Tom Pusateri (Juniper Networks), and Ken Carlberg (SAIC). This architecture involves defining so-called multicast "regions". These correspond to unicast routing domains, or contiguous collections of unicast domains, a primary goal being that a region's boundary is aligned with a corresponding unicast boundary; an important factor is to align unicast and multicast routing to simplify things such as interoperability and scaling. The concept of introducing multicast regions to the MBONE is not new. For example, independently managed M-OSPF regions have existed for some time. However, it was generally felt that there were no formal guidelines specified for operators and providers, many of whom arrive in the multicast (MBONE) arena not knowing a great deal about it. As a result, random tunnel configurations are often created, leading to an increasingly unstructured topology of ever-increasing size and complexity, leading further to operational problems. As such, the document was written as a general guide to facilitate a continued scalable evolution of the MBONE in a structured fashion. The general consensus of the group was that the document was rather too formal and over-specified. The feedback was that there should be a document, but it should concentrate on the "generic requirements of a border router". As such, the document is being re-worked and will be re-submitted before next IETF, where hopefully, a updated presentation will be given. Deborah Estrin gave an overview of what has changed in PIM-SM. One important change is that there is no longer any dependency on end-systems to know anything beyond the multicast address of a group. Routers should be the place that the complexity of dealing with protocol specifics are handled. Another change is to avoid "on-demand" RP mapping and liveness information, and instead use a-priori status distribution within a domain. Routers can then use an algorithmic mapping from a group to an RP, eliminating "startup delay". This is done as follows. All RP's indicate their willingness to be an RP to the Boot-Strap Router (BSR) for the domain, and the BSR floods this information through the domain using a flooding algorithm. When an RP goes down, the BSR notices and distributes the new list of RP's to all routers in the domain. This relieves the other routers of the responsibility of keeping track of whether or not the current RP is alive. Deborah also described the hooks for interoperating with a broadcast and prune style protocol in the backbone. A new type of tree, the (*,*,RP) tree, is composed of all groups that map to a certain RP. Each PIM Multicast Border Router (PMBR) joins the (*,*,RP) tree for all non-local groups, and uses these trees to receive the packets that it needs to inject into the backbone. When a PMBR receives a packet from outside the domain, it encapsulates it in a register and sends it to the RP for that group. The RP can send a Register-Stop message if it receives packets from the same source via different border routers. If a PIM domain is to act as a transit network, it must run the backbone routing protocol throughout the domain and carry backbone routes through the domain. If PIM-SM is the backbone, and it is interoperating with a leaf domain running DVMRP, the PMBR's now simply need to know of group memberships inside the domain (so that they can join the shared tree and inject packets into the domain). (*,*,RP) trees are not used in this case. The PIMv2 specification has been submitted as an Internet Draft, and comments are solicited. The interop document is in progress. The architecture document needs to be updated. USC's SunOS implementation of PIMv2 and the interop mechanisms is being tested and ported to IRIX. Cisco should have PIMv2 available soon. The ISI Routing Arbiter project is also implementing PIMv2. Deborah also talked briefly about an Inter-Domain RP architecture for PIM. The goals are to minimize globally-distributed RP information, to provide locality of RP selection, and to use an algorithmic mapping into a list of RP's as in PIMv2. A self-configuring hierarchy is a major goal. Tom Pusateri then talked about the DVMRPv3 specification. He had some specific questions about the Internet Draft that he wanted feedback from the working group on: - In section 3.2.1, is the language regarding capability flags OK? - Should the establishment of an adjacency (using Probe messages) be required before routes are exchanged? This could help to prevent "half-up" peerings, where one direction works but the other doesn't. However, it could break backwards compatibility with certain implementations. - DVMRP querier election is not necessary if IGMPv2 is used, since IGMPv2 specifies its own querier election. Should the DVMRPv3 document specify that a DVMRP router must implement IGMPv2? In addition, a question about the mechanics of tunnels was raised. Right now, DVMRP tunnels use two different protocols - IP protocol 2 (IGMP) for routing exchanges, and IP protocol 4 (IP encapsulation) for the data. This suffers from the typical problems that arise when the routing takes a different path than the data - routing information can get through (a firewall, for example) when data can not. The suggested solution is to encapsulate the routing information in IP protocol 4 packets as well. This is not backwards compatible but perhaps could get phased in. Second session: Thursday, June 27. Ajit Thyagarajan talked first, about IGMPv3. IGMPv3 is the third revision of the host/router group membership reporting protocol. It adds the ability for a host to not only describe its membership in a multicast group but only request traffic from certain sources. The host interface model is changed to allow applications to specify either an inclusion or an exclusion list with their group membership information. An inclusion list means "only traffic from these sources", and an exclusion list means "traffic from all but these sources". These requests are gathered from all applications and combined via a set of rules into inclusion or exclusion requests and are transmitted in response to queries from a multicast router. There are two types of host membership reports: a state change report, in which only changes from the previous state are reported, and a status report, in which the whole state of the host is reported. The former is used e.g. when joining a group, and the latter is sent in response to membership queries. These reports are gathered at the router, and a set of rules is applied to determine whether or not the router sends traffic from a particular source onto the network. In addition, the router might trigger a routing protocol action in response to a request (e.g. an exclusion report might trigger a source-specific prune). However, the host must be prepared to receive more than it asked for, as the subnet could either be transit or could have other hosts on it which desire to receive more traffic. Thus, filtering might occur at the IP layer of the host. Left to do are: send out the Internet Draft, detail interoperability mechanisms with IGMPv1 and IGMPv2, and complete the implementation. Next, Eric Crawley (Bay Networks) gave a talk on quality of service routing and what it means to IDMR. Eric provided an introduction to the challenge, which actually reflected a Bay customer's request to combine M-OSPF and RSVP to provide QoS routing over the wide-area type (T-1) links. The goal is to make more optimal use of topological redundancy, so that multiple paths can be used between multicast sources and destinations. The proposed scheme was as follows: new OSPF LSAs are used to advertise a router's link resources (buffers, bandwidth). These are combined with RSVP PATH messages, and M-OSPF's group membership LSAs. The receipt of an RSVP PATH message triggers a QoS Dijkstra calculation, which instantiates a QoS route for a pair. Only links with adequate resources are considered in the calculation. RSVP's resv messages (which travel from receivers towards a source) can lead to a router re-calculating its QoS route if the resv specifies different resources from those already computed. Routes may be "pinned", such that a QoS route does not change if new resources or new links become available. Routers send "resource reserved" LSAs on path on receipt of RESV messages, which allows new members to know which branches at which QoS are in use. These also prevent "resource available" advertisements from affecting a path currently in use. "Resource reserved" and "resource available" LSAs lead to scaling problems, for example, they can be sent out too frequently, or over too many paths. One solution, explicit routing (EROSPF), is for the router attaced to a source be the only router that calculates a QoS route, then have this router pass the route down the tree using opaque LSAs. Resource reserved LSAs are then only sent back to the computing router attached to the source. "Flushing" LSAs could be used to remove routes. There are many multicast issues yet to be solved with the scheme presented, such as border router behaviour, and interaction with shared tree protocols. This presentation was "one possible way" to achieve QoS routing with M-OSPF. The final presentation was given by John Crawford (University of Canterbury, Kent, UK). The title of the presentation was "A heuristic for lower cost multicast routing in the Internet". This scheme involved building a tree that is low cost in terms of bandwidth consumed by it (not building it). The heuristic was originally intended for ATM/B-ISDN networks, and used two metrics, but the presentation demonstrated its adaptation to Internet multicasting with only a single metric. The heuristic can be most suitably be integrated into M-OSPF. Lower cost trees are obtained by using a single metric and delay bounding the multicast tree to that of the receiver furthest from the multicast source. The heuristic achieves lower cost multicast trees by sharing paths, and not necessarily using the shortest path, to keep within the cost constraint. The tree is built by first evaluating the delay from a source to the furthest receiver, using a slightly modified Dijkstra algorithm. From M-OSPF's link state information, a source (calculating) node can easily deduce the path(s) to the different multicast destinations which call within the cost bound. The calculation involves starting with the node furthest from the source, then successively choosing the cheapest link back to the source, such that link cost still remains within the cost bound. All other paths are discarded. Simulation results show that the time required for multicast tree construction is closer to O(n * m) [n = no. of nodes, m = max node degree], than O(n^2) - the worst case time complexity of Dijkstra. However, results also show that for high degree network clusters connected by only a few links, the heuristic's time complexity can be much greater than O(n^2). This presentation was very well received, not least because of its clear and concise delivery by John, whose debut appearance it was at IDMR.