Source Packet Routing in Networking
charter-ietf-spring-00-04

The ability for a node to specify a forwarding path, other
than the normal shortest path, that a particular packet
will traverse, benefits a number of network functions,
for example:

o Some types of network virtualization, including multi-
topology networks and the partitioning of network
resources for VPNs
o Network path and node protection such as fast re-route
o Network programmability
o New OAM techniques
o Simplification and reduction of network signalling
components
o Load balancing and traffic engineering

Source-based routing mechanisms have previously been
specified for network protocols, but have not seen
widespread adoption other than in MPLS traffic engineering.
These applications may require greater flexibility and
per packet source imposed routing than can be achieved
through the use of the previously defined methods.

The SPRING working group will define procedures that
will allow a node to steer a packet along an explicit
route using information attached to the packet and
without the need for per-flow state information to be
held at transit nodes. Full explicit control (through loose
or strict path specification) is gained through a network
comprising only SPRING nodes, however SPRING must
inter-operate through loose routing in existing networks
and may find it advantageous to use loose routing for
for other network applications.

There is an assumed trust model such that any node
imposing an explicit route on a packet is assumed to
be allowed to do so, however administrative and trust
boundaries may strip explicit routes from a packet.

Initial work will focus on SPRING within in a single AS,
however design decisions must not preclude operation
of SPRING in across AS boundaries.

SPRING should support both centralised and distributed
path computation.

SPRING should both provide support for its use as
an OAM tool in SPRING enabled networks, and the
necessary OAM and other management tools needed to
manage a SPRING enabled network.

SPRING should avoid modification to existing data
planes that would make them incompatible with
existing deployments. Where possible, existing control
and management protocols must be used within existing
architectures to implement the SPRING function. Any
modification of or extension to existing architectures,
data planes, or protocols must be carried out in the
working groups responsible for the architecture, data
plane, or protocol being modified and in co-ordination
with this working group, but may be done in this
working group after agreement with all the relevant
WG chairs and responsible Area Directors.

The SPRING working group is chartered for the following
list of items:

o Identification and evaluation of use cases for SPRING .
These use cases must include a definition of the
data plane for the environment in which they are to be
deployed.

o Definition of any new data plane encodings and
procedures, required to implement the use cases. Such
procedures must include the necessary security
considerations.

o Definition of any new control plane mechanism
needed to enable the use cases. Modification to
existing control plane protocols must be done in
conjunction with the responsible IETF working group.

o Definition of management plane mechanism needed to
manage and operate a SPRING enabled network.

The SPRING working group will not work on any
mechanisms for use in networks that forward IPv4 packets.

The working group will develop the following documents:

o One or more documents describing SPRING use cases.

o Specification of high-level abstract architecture for
SPRING and requirements for modifications to existing
architectures to support SPRING.

o Specification of any required new procedures to support
SPRING use cases.

o One or more data plane extension requirements documents,
including documenting the impact on existing deployments
of the existing data plane.

o One or more control protocol extensions requirements
documents.

o Document interworking and co-existence between the
new procedures and the existing signalling and routing
protocols.

o Inter-operability reports pertaining to the implementation
of extensions supporting SPRING.

o Inter-operability reports pertaining to the implementation of extensions
supporting SPRING.