NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
John Moy <jmoy@casc.com>
Joel Halpern <jhalpern@newbridge.com>
General Discussion:ospf@gated.cornell.edu
To Subscribe: ospf-request@gated.cornell.edu
Archive: ftp://gated.cornell.edu/pub/lists/ospf
The OSPF Working Group will develop and field-test an SPF-based Internal Gateway Protocol. The specification will be published and written in such a way so as to encourage multiple vendor implementations.
Goals and Milestones:
· The OSPF NSSA Option
Request For Comments:
Minutes of the Open Shortest Path First IGP (OSPF) and Multicast Extensions to OSPF (MOSPF) Working Groups
A joint session of the OSPF and MOSPF Working Groups met on Wednesday, April 9th from 1300-1515 at the Memphis IETF. Minutes of the meeting follow:
John Moy gave a summary of the current status of the following documents:
The OSPFv2 specification, <draft-ietf-ospf-version2-10.txt>, is in IESG last call. It is expected to be published as an RFC, at Full Standard status, replacing RFC 1583.
The MOSPF specification, RFC 1584, needs to be updated. There are small problems in inter-area multicasting in the presence of virtual links, and when adding stub links to the forwarding cache entries. Also, the document should mention that when IGMPv2 is being used, IGMP elects the querier instead of using the OSPF DR. Finally, John wants to add a feature where ranges of multicast addresses can be configured in area border routers as being "area local." After these changes are made, the document can probably be submitted for Draft Standard status, as there are now a number of implementations.
The OSPF for IPv6 specification, <draft-ietf-ospf-ospfv6-04.txt>, was recently updated: a) the IPv6 pseudo-header was added to the OSPF packet checksum, to protect against corruption of the IPv6 header, b) MTU was added to the Database Description packet, porting the MTU mismatch fix from OSPFv2, and c) the set of LSAs that cannot be flooded through stubs areas was clarified, allowing certain AS-scoped LSAs on a case-by-case basis. The only other pending changes involve the IPv6 encapsulation: the setting of the priority field and possibly the setting of the TTL. The specification is still awaiting implementation experience before it will be published as an RFC.
Dave Jacobson from IBM made the following patent disclosure: "IBM believes that it has patents (4644532, 4827411) which may relate to OSPF and in accordance with the intellectual property rights procedures of the IETF standards process, IBM is willing to offer non-exclusive licenses under reasonable and non-discriminatory terms and conditions. Any party wishing to request a license should write to: IBM Director of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood, New York 10594". No further information was made available.
Rob Coltun presented the latest changes to his Opaque-LSAs draft, which will be published as an Internet Draft after the meeting. Two changes have been made: a) separate LS types have been assigned to Opaque-LSAs with link-local, area, and AS flooding scope (LS types 9, 10 and 11, respectively), and b) the flooding rules were changed so that Opaque-LSAs with AS flooding scope will not be flooded into/throughout stub areas. It was decided to give administration of the Opaque type field to IANA, since we already have a conflict (between Rob's ARA proposal and the MOSPF pruning proposal, see below). Sandy Murphy questioned why the stub area rules were different for Opaque-LSAs versus the LSAs in OSPF for IPv6. The reason is that the "flood even if unrecognized" bit and the increased size of the Options field in IPv6 allows us finer control than the all or nothing decision (where nothing seems most appropriate for stub areas) possible with Opaque-LSAs. Since we are now out of Options bits in OSPFv2, we expect all new OSPFv2 options to be implemented using Opaque-LSAs. For this reason, we will try to get the Opaque-LSA document published as a Proposed Standard as soon as possible.
Rob Coltun then presented an application of Opaque-LSAs that he developed together with Juha Heinanen (Telecom Finland) and Yiqun Cai (Nortel). Called the Address Resolution Advertisement (ARA), it uses Opaque-LSAs to advertise mappings between IP addresses (or OSPF Router IDs) and ATM NSAPs. This allows the establishment of control-driven shortcuts across legacy ATM clouds. This work was also presented to the ION Working Group.
Pat Murphy (USGS) talked about the work he has been doing to update the NSSA area specification (RFC 1587). He has added two features: the ability to omit summary advertisements from NSSA areas, and the ability to configure which area border routers do the translation from type-7 LSAs to type-5 LSAs. The first can keep the NSSA database size even smaller (although it can't be used when the NSSA area employs "private" defaults), while the second can optimize routing when aggregation is taking place (and so forwarding addresses cannot be used). There was discussion of whether it would be better to have all border routers perform the translation, analogous to OSPF's treatment of summary-LSAs. Pat also updated the type-7 route calculation to make it compatible with the updated external route calculation in the latest OSPFv2 draft.
Sanjay Kamat (IBM) presented a proposal for QoS path management with RSVP <draft-guerin-qospath-mgmt-rsvp-00.txt>. The goal of this work is to have RSVP set up the paths selected by QoS routing algorithms, and provide support for route pinning while detecting loops in path setup. Other goals were to change RSVP as little as possible, keep its soft state model, and work with any QoS routing protocol. The interface between RSVP and routing is modified, with RSVP passing the Tspec as well as source and destination addresses. The RSVP PATH messages are then forwarded along the path selected by the QoS routing algorithm. This work was also presented to the QoS routing Working Group.
Tony Przygienda (FORE) gave an update on "QoS Routing Mechanisms and OSPF Extensions," <draft-guerin-qos-routing-ospf-01.txt>, joint work done by himself and Guerin, Kamat, Orda, and Williams (IBM). Tony restricted his talk to the changes since the last meeting. Instead of changing the format of router-LSAs, they now encode their metrics using OSPF's TOS encodings. To enhance backward capability, TOS values were chosen so that OSPF implementations which only look at 4 TOS bits would interpret their bandwidth metric (TOS 0x10100) as "maximize throughput," and their delay metric (TOS 0x11000) as "minimize delay." Metric values are encoded using exponential encoding, with a 7-bit exponent and a 5-bit mantissa, to fit in OSPF's 16-bits. They are also using a new Option bit, the Q-bit, to indicate that a router is running the QoS enhancements. Ongoing work includes OSPF area support (whether to support heterogeneous areas, and how to aggregate QoS metrics), and extensions to additional metrics (such as jitter).
John Moy presented work to add prune support to MOSPF. This has two independent parts. The first allows unnecessary wild-card multicast receivers to be pruned from multicast delivery trees during inter-area and inter-AS multicasting. Prune packets (a new OSPF packet type) are sent upstream (toward the source) when forwarding cache entries are built with no downstream interfaces. Prune packets contain a list of the wild-card receivers that need not be included in the delivery tree; this allows prune maintenance to be delegated to the wild-card multicast receivers themselves.
Jeffrey Zhang thought prune information should be advertised in LSAs; John's stated reason for using packets was that flooding the prune information forces routers to hold more information than they need. Tom Maufer (3com) said that prunes and prune deletes should be made reliable, rather than just relying on timeouts. Hal Sandick (IBM) asked whether interaction with shared tree multicast routing protocols has been considered; John admitted that he hadn't spent much time on that issue.
The second part of the work allows IGMPv3's source-specific group membership information to be advertised within MOSPF. Two new LSAs, the source-join-LSA and source-leave-LSA, are used. Both are built on top of the area-scoped Opaque-LSA. Both have properties similar to the MOSPF group-membership-LSA: they are specific to a single area and are summarized at area boundaries going up the hierarchy (but not down).
This work will be published as an Internet Draft after the meeting.
The meeting ended with Path Murphy describing his large inter-agency OSPF network, and the circumstances in which he would like to prefer inter-area routes over intra-area routes. Pat proposed protocol changes to accomplish his goal. Some discussion ensued as to whether it was better to make protocol changes, or to just configure multiple subnets per link, which could achieve the same thing.