Draft MPLS Minutes Framework Document - Ross Callon Ross made a brief presentation on the framework document. Another draft was submitted. In it, several sections of the former draft were fleshed out. The framework document is also being used to capture architecture discussions which have lead to particular decisions in the architecture document. The hierarchy and multicast sections were pointed out as in need of further work. MPLS Architecture - Callon, Rosen, Viswanathan Eric Rosen presented the draft. An extensive number of architectural issues have been agreed and settled. These include the semantics of labels, the concept of equivalence classes, the need for hierarchy and thus the label stack, the need for explicit routes, a preference for topology based (actually control) label distribution vs traffic (data) based setup. Several important issues remain to be resolved. These were discussed extensively during the meeting, but with no resolution. The discussion did have the effect of getting a large number of people informed on the issues. The most prominent issues are: 1. Distributed vs Egress control The debate here is one of both versus egress only. The observation was made that the two modes can interoperate in a natural way. Arun on the other hand argues that egress control offers all the capabilities of distributed control and more, so why have two. In particular, egress control allows the level of aggregation to be consistent across the network. Eric Rosen pointed out that this only holds when you want to explicitly configure granularities other than coarse or fine. Those in favor of the distributed method point to the issues of scalability and convergence time as weaknesses of egress control. 2. Loop Prevention Rick Bovie presented the loop prevention scheme that is in the current architecture draft. The scheme is based on the diffusion algorithm. It pins down routes until it can verify that a change will not result in a loop. The effects of this are that for traffic moving from a good path to a better path will continue to use the good path. Traffic which is being black-holed may be black-holed longer. The architecture team believes that this is a workable approach with acceptable trade-offs. The point of contention is whether the algorithm is mandatory or optional. It was pointed out that in all cases except ATM with VC merge, there are other mechanisms to deal with looping packets. Also, Jeremy Lawrence made a presentation showing that some classes of ATM switches have the capability of using fair queuing or fair buffering schemes to contain the effects of loops in the VC merge case. 3. LDP Transport It is agreed that LDP transactions need to be reliable, but there is no agreement on how that reliability should be achieved. The architecture draft was accepted as the baseline text for the working group. LAN Encapsulation (Ghanwani) IBM presented an update of the LAN proposal to carry labels in the destination MAC address field. The most significant changes are: 1) switches are now required to swap labels 2) labels are placed in the source address of label update messages to allow bridges to learn them The authors will continue to refine their draft. MPLS encapsulation format (Rosen) Eric presented the changes to his encaps draft, namely that the label is now 20 bits, the tos 3 bits and the TTL 8 bits. It was proposed that the document be accepted as baseline text. Vijay objected to the presence of a LAN encapsulation in that document given that the above LAN encaps has also been proposed. Rosen agreed to drop the LAN section from his document (for now). It was then agreed that rough consensus existed to promote the draft to a working group document. Soft State Switching (Blake) IBM presented an update of their draft and then moved that it be accepted as baseline text. This was objected to on the grounds that a) there was already another existing draft on the subject and b) their draft was a late submission. After some discussion it was agreed that the authors of the two drafts would work together to create a combined document. The two drafts appear to be quite reconcilable. MPLS in VC environments (Doolan/Esaki/Demizu) The soon-to-be-published draft addresses problems related running MPLS in ATM networks where the LSR's are not directly connected. In this situation, the label (VPI/VCI) will not be preserved between the logically adjacent LSR's. The document points out that there are two functions of a label. These are 1) to provide the value upon which something is switched and 2) to provide the binding between the switching operation and the associated equivalence class. When LSRs are directly connected the same value is easily used for both functions. But when ATM switches are not directly connected, the VPI/VCI cannot be used as a binding as the intermediate switch may not preserve the VPI/VCI from the incoming to the outgoing link. The authors plan to continue developing their draft. VC pool (Noritoshi) Setting up ATM SVCs require signaling and this will introduce delay is setting up LSPs. The proposal is to pre-create a pool of VCs. When a tag is allocated, the VC is then picked in the LDP BIND procedure. Two modes of Explicit Label Distribution Protocol (Katsube) There are two modes of assigning labels, edge initiated and distributed. The TDP specification could be classed in both categories where the conservative mode over ATM represents a edge initiated approach and the liberal mode the distributed. The distribute approach are more light-weight as it only is link by link, while the edge initiated approach implies end to end signaling. Edge initiated is desirable for controlling LSPs with arbitrary granularity, while distributed is adequate for multicast, RSVP driven or unicast with limited granularity. Double Identification Label Switching - DILS (Droz) The goal of this draft is to have a scalable solution for n endpoints, avoid the n**2 cross connect problem, preserve ATM traffic characteristics, and not require hardware changes. The DILS concept involves the use of flow merging and connection setup as proposed by ARIS and the use of VP merging. Two cases are supported a symmetric and an asymmetric. The proposal is considered complementary to ARIS, it is possible to extend with QoS support. It was claimed that this could be achieved with no ATM hardware changes. The presentation generated quite a bit of discussion. It was pointed out that most ATM hardware does not allow the VCI replacement function to be independent of the VPI replacement, since these operations are coupled in normal ATM. This means that in a worst case, the number of cross connects required is still n**2. Performance Issues in VC merge MPLS Switches (Widjaja) VC merging requires that all the cells of a packet be buffered before the first cell can be transmitted. This changes the queueing behavior of ATM systems. To investigate the effects of VC merge a series of comparative simulations was run across various utilizations and traffic models. The simulations showed that within normal operational limits that the additional buffering for VC merging is minimal and that best effort traffic would benefit from VC merging. As utilization increases, the additional drops due to VC merge decreases. Multi-Protocol Labels Switching: Performance and QoS Issues (Crosby) The requirements on improved forwarding performance has to be better defined. What is the metrics? The intention is to explicitly describe the performance requirements and include them in the Framework document. CSR Experimental Operation (Esaki) The WIDE project is an experimental network in Japan using legacy routers and CSRs all based on ATM. Hiroshi gave an update of their progress, pointing out the various service offerings and pointing out that the project incorporates hardware and software from different vendors. Scalability Issues in MPLS over ATM (Wang) Scalability is a major concern for MPLS over ATM. While VC merging address this issue, it may not be available on all platforms. This ID analyzes the scalability of MPLS without VC merge in terms of the size of the VPI/VCI space. If all 28 bits in the VPI/VCI field are available for label switching, then the number of end to end LSPs that can be supported is equivalent to 32k endpoints. Given that LSPs will end on routers rather than hosts, this is quite sufficient to support most real networks. Support of different services between the same end points will consume additional VPI/VCI space. However, the conclusion is that the combined VPI/VCI space in ATM should still be able to support networks of sufficient size. In the ensuing discussion, it was pointed out that in most cases the size of the cross connect tables of the ATM switch would be the limiting factor. ====================================================================== George Swallow Cisco Systems (508) 244-8143 250 Apollo Drive Chelmsford, Ma 01824