A new IETF working group has been formed in the Routing Area. For additional information please contact the Area Directors or the WG Chairs. Source Packet Routing in Networking (spring) ------------------------------------------------ Current Status: Proposed WG Chairs: Alvaro Retana <aretana@cisco.com> John Scudder <jgs@juniper.net> Assigned Area Director: Stewart Bryant <stbryant@cisco.com> Mailing list Address: status@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/status Archive: http://www.ietf.org/mail-archive/web/status/current/maillist.html Charter: 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 network functions may require greater flexibility and per packet source imposed routing than can be achieved through the use of the previously defined methods. In the context of this charter, 'source' means 'the point at which the explicit route is imposed'. 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-path state information to be held at transit nodes. Full explicit control (through loose or strict path specification) can be achieved in 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. The initial data planes that will be considered are MPLS and IPv6. 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. For each data plane technology that SPRING specifies, a security analysis must be provided showing how protection is provided against an attacker disrupting the network by for example, maliciously injecting SPRING packets. There are a number of serious security concerns with source routing at the IP layer [RFC 5095]. As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negotiation for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc. Initial work will focus on SPRING within in a single AS, however design decisions must not preclude operation of SPRING across AS boundaries. In such multi-AS deployments, the previously-stated trust model would still apply. SPRING should support both centralised and distributed path computation. The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks. The SPRING procedures may also be used as a tool for OAM in SPRING enabled networks. SPRING should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function. Any modification of or extension to existing architectures, data planes, or control or management plane protocols must be carried out in the working groups responsible for the architecture, data plane, or control or management plane 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 requirements for any new data plane encodings and procedures, required to implement the use cases. Such procedures must include the necessary security considerations. o Definition of requirements and if necessary any new control plane mechanism needed to enable the use cases. o Definition of requirements and if necessary management plane mechanisms 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. Milestones: Jul 2014 - One or more documents describing SPRING use cases. Nov 2014 - Specification of a high-level abstract architecture for SPRING. Dec 2014 - Requirements for modifications if any to MPLS architecture to support SPRING use cases. Jan 2015 - Requirements for modifications if any to IPv6 architecture to support SPRING use cases. Mar 2015 - Specification of any required new procedures to support SPRING use cases. Jul 2015 - One or more data plane extension requirements documents, including documenting the impact on existing deployments of the existing data planes. Jul 2015 - One or more control protocol extensions requirements documents. Jul 2015 - Management requirements document. Nov 2015 - Specify the OAM mechanisms needed to support SPRING. Nov 2015 - Document inter-working and co-existence between the new procedures and the existing signalling and routing protocols. Jan 2016 - Inter-operability reports pertaining to the implementation of extensions supporting SPRING. Feb 2016 - Recharter or close WG.
