CURRENT_MEETING_REPORT_ Reported by Deborah Estrin/USC and Tony Li/cisco Minutes of the Source Demand Routing Working Group (SDR) Changes to the Specification Changes to the specification were presented and discussed. Major modifications were made to support interior SDRP. The new packet header format was presented. All packets now carry a hop count, which formerly was only in data packets. All packets now carry target router and notification fields, even though only control packets use them. Notification uses a byte which would be necessary for alignment anyhow, so this causes four bytes of overhead on data packets. The source route length is now the number of IP addresses, not the number of bytes. The next hop pointer also now is in terms of addresses. The source route now supports interior routing due to the need expressed at the previous SDRP BOF for source demand routing within domains. Source routes now contain three types of entries, all of which are syntactically IP addresses. An entry may be a normal IP address, or an AS number, or a change in source route attributes. An AS number is encoded in the low order two octets of network 128.0.0.0. Changed source route attributes are encoded in the low order three octets of 127.0.0.0. Currently, the only change possible is to change the strict/loose source route bit. This accommodates source routes which need a mix of strict and loose source routing. There are changes to forwarding to match the new source route format. If the address in the source route that is currently being processed is a normal IP address, then forwarding checks to see if it matches the local address and if so, looks at the next address in the source route. Otherwise the packet is forwarded to the indicated address using normal IP forwarding. If the address in the source route encodes an AS number that matches the local AS#, then forwarding looks at the next entry in the source route; otherwise the packet is forwarded to the indicated AS looking at D-FIB. If the address in the source route encodes a change in attribute type, then the SDRP speaker reaches in and sets the attribute bit accordingly and looks at the next source route entry for processing. SDRP Overview A brief SDRP overview was presented for new folks; see the BOF Minutes from the previous IETF or the Unified Architecture document for background. SDRP Usage Document The Group discussed a draft of the SDRP usage document distributed before the IETF. SDRP can be used in the near-term to provide special routes that compliment existing IGP and BGP/IDRP routing. SDRP can be phased into the operational Internet without wholesale replacement of routing. At the same time as the Group is proceeding with protocol specifications for nearer-term experimentation, longer-term issues are already under consideration. To provide a sense of ``where we are headed'' with this protocol and the Unified Architecture in general, a companion document on SDRP futures has also been drafted. In the packet format and forwarding protocol specification it is not specified how an SDRP router that originates an SDRP packet acquires an SDRP route. An SDRP route is defined as a sequence of domain identifiers and/or IP addresses, or a combination; the route may be strict or loose. The usage document should discuss mechanisms for acquiring SDRP routes using EXISTING routing information distribution mechanisms (BGP/IDRP). In particular, it will cover the following three sources of routes: 1. BGP/IDRP routes 2. Manually configured routes 3. Route fragments Any legal BGP or IDRP route is, by definition, a legal SDRP route, so long as there are SDRP speakers at appropriate points along the path. Every BGP/IDRP speaker may maintain information about multiple feasible routes to a destination (routes advertised by different neighbors). But a BGP speaker chooses at most one route to be active (selected), and an IDRP speaker may choose more than one route to be active (selected) only if all selected routes have different ``distinguishing attributes''. As a result, the currently active (selected) IDRP/BGP route may not be appropriate for the packet. One of the simplest forms of SDRP route acquisition is to select among the alternative routes advertised by the node's neighbors. This requires NO modifications to BGP/IDRP. It does require development of appropriate route selection rules, both manual and semi-automated, for selecting particular BGP/IDRP routes to be used as SDRP routes. Network administrators can also create SDRP routes by examination of network topology BGP/IDRP databases, or manually collecting network information through active probing (traceroute). The operational status of routes can be determined dynamically using the passive and active mechanisms defined in SDRP packet forwarding, allowing the scheme to adapt to topological changes. For the usage document, examples of useful manual configurations need to be given. It must be emphasized that PROBE needs to be used to detect black hole routes and the utility of having several SDRP routes as fallback routes to somewhat make up for the fact that these will be ``static'' due to manual configuration. Route fragments from different BGP/IDRP routes can be used, in part or whole, to create desired SDRP routes that do not appear in the node's neighbors' BGP/IDRP tables. This allows the administrator to ``cut and paste'' to create new routes. If SDRP is used within a domain, an IGP route can be used as an SDRP routes. Additional information derived from IGP can also be used to construct routes, e.g., the OSPF link state database for reachability within the OSPF system. Interior SDRP is an area that in particular needs further discussion and development of a usage model. For example, there is a need to: o Clarify how you get information about exit points into the interior. o Investigate the use of information that OSPF and ISIS carry already. o Consider adding the ability to query BGP speakers internally. Another mechanism not given in the specification is how a source host's SDRP-speaking border router maps a particular packet to a particular SDRP route. This is not part of the protocol specification because it can be left to local control; we need not be coordinated across the Internet, or even across the set of routers on a single path. However, to use SDRP, the network administrator must be able to configure the information used to map host-generated payload packets to appropriate routes, therefore it must be addressed in the usage document. The mapping indicates whether a packet can be sent out using the BGP/IDRP route; and if not, which available SDRP route can be used (if any). A domain may choose any mapping function that is unambiguous and whose input information can be found in the payload packet or locally to the router (e.g., based upon incoming interface); but may ``pay for'' more sophisticated mappings. Good examples need to be developed for the usage documents as well as clarification on where the mapping/classification is done and note the tradeoffs between doing it closer to the host and at the border router. BGP/IDRP and SDRP routes have transit policy qualifications associated with them. The syntax and semantics of SDRP policies should be consistent with transit IDRP/BGP policies. The Group should probably proceed by initially using the existing BGP/IDRP policy semantics and syntax and evaluating the need for extensions after gaining some experience. For the next IETF the Group will review the IDRP policy language and identify if there are unmet needs for SDRP. In the current specification, the Working Group disclaims any attempt to provide secure/verifiable enforcement of transit policies. The essential tools needed for this security service are more a function of the authentication and integrity mechanisms available in the protocol providing delivery service for SDRP, than of SDRP itself. However, transit policy conformance can be audited by sampling data to identify violators. Spot checks can be effective and are used in many other kinds of systems (computerized and manual). Auditing procedures and sampling rules are a subject for local control and may vary across different SDRP routes. It would be useful to develop some examples for the usage document. The only planned modification of BGP/IDRP is an optional attribute indicating that a particular domain supports SDRP and optionally specifies address(es) of SDRP speaker(s) in the domain. This is important for route selection and forwarding decisions. There are two proposals for this function so far and the arguments for and against will be discussed shortly on the SDRP mailing list. SDRP supports interior policy routing by allowing SDRP routes to carry IP addresses. This can be used to direct traffic via configured paths in the source domain. It can also be used to direct routing of packets within other domains; for example, by specifying a particular exit router for a transit domain. Particular routes within the destination domain can also be specified; but this requires detailed knowledge of the topology and addressing of other domains which requires mutual agreements for information update between domain administrators. The possible use of OSPF and ISIS information and the implications of attempting to use this (or not) with other interior routing protocols such as RIP, or IGRP should be discussed in the usage document. The use of IBGP for this purpose should also be documented. The Unified Architecture is designed to allow evolution. SDR was also designed to allow innovation without global coordination. The Group is working to specify parts of the protocol that could be implemented and used in the short-term such that they will interwork with other parts of the architecture still under development. In particular, the packet format and forwarding protocol have been specified while details of SDR route computation are still under development. Mechanisms for route computation and even information distribution/collection can be changed more readily than packet forwarding mechanisms because route computation is a local matter. Information distribution concerns some subset of routers or domains whereas packet forwarding procedure must be agreed upon by all routers that implement SDRP. Important but evolving aspects of the architecture include: o Route construction. o Policy language. o Route setup. o Multicast routing. o Alternate path routing for reservation-oriented (virtual circuit) traffic. The Group wants to extend route construction mechanisms to obtain routes that conform to source-specific policies where a route's use is restricted to certain sources, or QOS requirements where a route supports a particular performance or policy related QOS (color), and/or path-constraint policies where a route must pass through or avoid particular transit domain(s). Routes available via IDRP are the result of path selection processes in all the intermediate IDRP speakers between the source and destination. Mechanisms are needed for the source to obtain information about other routes that it is allowed to use but that intermediate domains filtered out as a result of their path preferences. Different approaches can be characterized to route construction according to whether construction is based on distributed or centralized processing. For example: using an IDRP route is a form of distributed processing since the route is constructed hop-by-hop by nodes on a path. Collecting inter-domain topology/policy information from around the network and computing a route at the source is a form of centralized processing. Route fragments represent intermediate points where the source centrally controls the acquisition and concatenation of fragments, but the fragments themselves represent the result of a distributed computation. Query is one example mechanism where a source domain SDRP speaker queries its immediate neighbor IDRP domains to get all available routes to a particular destination (possibly with QOS specified as well). The SDRP speaker could also query non-neighbor IDRP speakers; but this raises the question of heuristics for deciding whom to query, which is still a subject for further research. Query is an example of centralized processing and can also be used to obtain route fragments. The Extract mechanism is a second proposed mechanism for on-demand SDRP route acquisition. For example, the source could send an extract request to the destination indicating desired QOS and possibly exclusionary transit information (e.g., what transit it does NOT want to use). The destination would then cause IDRP to propagate back routes that fit the characteristics specified by the source. The routes would NOT be stored in the RIBs en route back to the source; rather the information would be passed along on an FYI basis. Extract is an example of distributed processing and could also be extended to send extract requests to a preferred transit domain for it to initiate the extract. Extract could also be used to obtain route fragments. The big question is how to constrain the propagation of the return information; hop-count limits, limits on the number of routes propagated by each domain are possibilities, each of which trades off overhead for some loss of information. Other schemes for collecting information and computing routes are the subject of ongoing research. However, the combination of extract, query, and route fragment mechanisms may be adequate to meet most needs; this needs further study. A common language is needed for specifying policy constraints on all routes. This would allow other domains to do policy computations to determine feasible routes. The language must be extensible. For example, in response to a policy query, a domain may respond with its policy configuration. The policy language would look like a boolean expression; and policy computation would consist of evaluating this expression. Syntactically, the expression appears as a series of terms; satisfying any term satisfies the expression. Possible variables include: o QOS of the packet. o Source domain. o Source address. o Destination domain. o Destination address. o Transport protocol. o Application protocol. o Time of day. o Inter-domain path in use. Terms that contain unrecognized variables would be ignored. The initial specification for packet format and forwarding includes a full SDRP route in every packet sent. When the duration of a packet stream is significantly longer than the end-to-end delay, and if the payload in the packets is small, it is worth establishing state information in SDRP speakers along route, instead of carrying a full SDRP route in every packet, i.e., ``setup''. Once state is established, the source can rely on a route identifier in each packet and thereby reduce SDRP packet header size and processing time. However in designing a setup protocol it is important to not IMPOSE setup on all SDRP speakers (might be short on state space or might not otherwise wish to support setup). Strawman Proposal A strawman proposal for setup operations was presented. SDRP multicast would coexist and interoperate with IDRP/BGP multicast routing mechanisms. The Group anticipates more than the single IP multicast routing model currently used in the Internet. IDRP may be used for setting up the multicast distribution trees (or branches thereof) when the generic routes satisfy the requirements of the application and group (i.e., QOS). In particular there will be complementary mechanisms that are more efficient than DVMPR or MOSPF style multicast for supporting sparse multicast groups. Both IDRP and SDRP will be used to support these mechanisms. SDRP would set up multicast distribution trees (or branches thereof) when the generic routes do not meet the needs of the application and group. SDRP can be used to support alternate path routing for reservation (or more generally virtual circuit) traffic. Source routing is good for achieving alternate path routing because it has inherent loop avoidance and it avoids placing burden on intermediate switches to compute and retain multiple routes to each destination. Alternate path routing is particularly important for reservation traffic where a call setup request may be rejected due to insufficient resources at some intermediate switch/link as a result of heavy utilization. In this case, the source would like to attempt alternate routes that do not go through the bottleneck link. SDRP can provide a source with alternate, loop free, routes; particularly appropriate when SDRP setup is used. A recent Internet-Draft by Rob Coltun and Marco Sosa also concluded that source routing is the best means of achieving alternate path routing for virtual circuit routing. Given that a route must have sufficient resources to accommodate a reservation flow (i.e., stream, call), it might be useful for the source to maintain recently measured load levels on those links in the network that it uses frequently; for example from those links used by active flows. There are open research issues to resolve in the inter-domain case where detailed information of remote domains is not available. Because SDRP can be used to support interior routing, SDRP could be used for alternate path routing within areas of a domain and within domains. Initially, it may be simplest to have the source try to use an alternate domain level route when a reject is received from a remote domain; this may be justified if one assumes that the hop-by-hop routing choice used in that domain to traverse the domain does reflect long-term utilization in that domain. There is much more to be said on all of these subjects. Projects and Milestones Projects and milestones were discussed. The following is a list of topics to be discussed and people interested in working on them. Usage Document (Draft before July IETF.) Deborah Estrin, Yakov Rekhter and Peter Ford. BGP/IDRP Attributes Draft (Draft by May.) Tony Li, Yakov Rekhter and Deborah Estrin (referee). Prototype (Working prototype for others to see by June.) Daniel Zappala and Tony Li will look it over. Setup Specification (Draft before July IETF.) Deborah Estrin, Tony Li and Osmund deSouza. Info. Distribution/Route Selection (Draft description of Extract Mechanism (not specification) and more detailed plan for how to proceed in short and mid-term by July IETF.) Tony Li, Steve Hotz, David Bridgam dab@epilogue.com, Yakov Rekhter and Brijesh Kumar. Policy Language (Presentation and discussion at July IETF; draft document for November.) Tony Li, David Karrenberg, Peter Lothberg, Steve Hotz, Sue Hares and Steve Willis. Multicasting (Possible draft for November.) Deborah Estrin and Osmund deSouza. Use of SDRP for Adaptive Routing (Discuss at July or November IETF; In the mean time discuss with VCROUTE BOF.) Deborah Estrin and Daniel Zappala. Attendees Vikas Aggarwal aggarwal@jvnc.net Michael Anello mike@xlnt.com Tony Bates tony@ripe.net David Bolen db3l@ans.net Ed Brencovich edb@dss.com David Bridgham dab@epilogue.com Jeff Carman tcarman@bnr.ca James Cassell jcassell@dsac.dla.mil David Conklin conklin@jvnc.net Dave Cullerot cullerot@ctron.com Tony DeSimone tds@hoserve.att.com Osmund DeSouza osmund.desouza@att.com Kurt Dobbins kurtdob@ctron.com Kishan Dudkikar kishan@icm1.icp.net Deborah Estrin estrin@isi.edu Peter Ford peter@goshawk.lanl.gov Karen Frisa karen.frisa@andrew.cmu.edu Robert Hinden hinden@eng.sun.com David Jacobson dnjake@vnet.ibm.com Matthew Jonson jonson@server.af.mil Merike Kaeo merike@alw.nih.gov Daniel Karrenberg daniel@ripe.net Padma Krishnaswamy kri@sabre.bellcore.com Giri Kuthethoor giri@ms.uky.edu Mark Laubach laubach@hpl.hp.com Tony Li tli@cisco.com Kim Long klong@sura.net Charles Lynn clynn@bbn.com Glenn Mansfield glenn@aic.co.jp Jun Matsukata jm@eng.isas.ac.jp David Meyer meyer@ns.uoregon.edu Greg Minshall minshall@wc.novell.com Dennis Morris morrisd@imo-uvax.disa.mil Peder Chr. Noergaard pcn@tbit.dk Erik Nordmark nordmark@eng.sun.com Zbigniew Opalka zopalka@agile.com Laura Pate pate@gateway.mitre.org John Penners jpenners@advtech.uswest.com Maryann Perez perez@cmf.nrl.navy.mil Yakov Rekhter yakov@watson.ibm.com Robert Reschly reschly@brl.mil Ben Robinson ben_robinson@vnet.ibm.com Manoel Rodrigues manoel_rodrigues@att.com Shawn Routhier sar@epilogue.com Hal Sandick sandick@vnet.ibm.com Vilson Sarto vilson@fapq.fapesp.br John Scudder jgs@merit.edu Kanan Shah kshag@cmf.nrl.navy.mil Andrew Smith asmith@synoptics.com Martha Steenstrup msteenst@bbn.com Bernhard Stockman boss@ebone.net Terry Sullivan terrys@newbridge.com John Tavs tavs@vnet.ibm.com Marten Terpstra marten@ripe.net Kannan Varadhan kannan@oar.net Chuck Warlick warlick@theophilis.nsfc.nasa.gov Steven Willis steve@wellfleet.com Richard Woundy rwoundy@vnet.ibm.com