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