draft-ietf-spring-ipv6-use-cases-00.txt   draft-ietf-spring-ipv6-use-cases-01.txt 
Spring J. Brzozowski Spring J. Brzozowski
Internet-Draft J. Leddy Internet-Draft J. Leddy
Intended status: Informational Comcast Intended status: Informational Comcast
Expires: November 10, 2014 I. Leung Expires: January 4, 2015 I. Leung
Rogers Communications Rogers Communications
S. Previdi S. Previdi
M. Townsley M. Townsley
C. Martin C. Martin
C. Filsfils C. Filsfils
R. Maglione, Ed. R. Maglione, Ed.
Cisco Systems Cisco Systems
May 9, 2014 July 3, 2014
IPv6 SPRING Use Cases IPv6 SPRING Use Cases
draft-ietf-spring-ipv6-use-cases-00 draft-ietf-spring-ipv6-use-cases-01
Abstract Abstract
Source Packet Routing in Networking (SPRING) architecture leverages Source Packet Routing in Networking (SPRING) architecture leverages
the source routing paradigm. A node steers a packet through a the source routing paradigm. A node steers a packet through a
controlled set of instructions, called segments, by prepending the controlled set of instructions, called segments, by prepending the
packet with SPRING header. A segment can represent any instruction, packet with SPRING header. A segment can represent any instruction,
topological or service-based. A segment can have a local semantic to topological or service-based. A segment can have a local semantic to
the SPRING node or global within the SPRING domain. SPRING allows to the SPRING node or global within the SPRING domain. SPRING allows to
enforce a flow through any topological path and service chain while enforce a flow through any topological path and service chain while
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2014. This Internet-Draft will expire on January 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IPv6 SPRING use cases . . . . . . . . . . . . . . . . . . . . 3 2. IPv6 SPRING use cases . . . . . . . . . . . . . . . . . . . . 3
2.1. SPRING in the Home Network . . . . . . . . . . . . . . . 4 2.1. SPRING in the Home Network . . . . . . . . . . . . . . . 5
2.2. SPRING in the Access Network . . . . . . . . . . . . . . 5 2.2. SPRING in the Access Network . . . . . . . . . . . . . . 6
2.3. SPRING in the Data Center . . . . . . . . . . . . . . . . 6 2.3. SPRING in the Data Center . . . . . . . . . . . . . . . . 6
2.4. SPRING in the Content Delivery Networks . . . . . . . . . 6 2.4. SPRING in the Content Delivery Networks . . . . . . . . . 7
2.5. SPRING in the Core networks . . . . . . . . . . . . . . . 7 2.5. SPRING in the Core networks . . . . . . . . . . . . . . . 8
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Informative References . . . . . . . . . . . . . . . . . . . 9 6. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Source Packet Routing in Networking (SPRING) architecture leverages Source Packet Routing in Networking (SPRING) architecture leverages
the source routing paradigm. An ingress node steers a packet through the source routing paradigm. An ingress node steers a packet through
a controlled set of instructions, called segments, by prepending the a controlled set of instructions, called segments, by prepending the
packet with SPRING header. A segment can represent any instruction, packet with SPRING header. A segment can represent any instruction,
topological or service-based. A segment can represent a local topological or service-based. A segment can represent a local
semantic on the SPRING node, or a global semantic within the SPRING semantic on the SPRING node, or a global semantic within the SPRING
skipping to change at page 3, line 28 skipping to change at page 3, line 28
described in [I-D.filsfils-spring-segment-routing-mpls] could be described in [I-D.filsfils-spring-segment-routing-mpls] could be
leveraged to provide SPRING capabilities in an IPv6/MPLS environment. leveraged to provide SPRING capabilities in an IPv6/MPLS environment.
However, there are other cases and/or specific network segments (such However, there are other cases and/or specific network segments (such
as for example the Home Network, the Data Center, etc.) where MPLS as for example the Home Network, the Data Center, etc.) where MPLS
may not be available or deployable for lack of support on network may not be available or deployable for lack of support on network
elements or for an operator's design choice. In such scenarios a elements or for an operator's design choice. In such scenarios a
non-MPLS based solution would be preferred by the network operators non-MPLS based solution would be preferred by the network operators
of such infrastructures. of such infrastructures.
Specifically, there are a class of use cases that motivate an IPv6 In addition there are cases where the operators could have made the
data plane. We identify some fundamental scenarios that, when design choice to disable IPv4, for ease of management and scale
(return to single-stack) or due to an address constraint, for example
because they do not possess enough IPv4 addresses resources to number
all the endpoints and other network elements on which they desire to
run MPLS.
In such scenario the support for MPLS operations on an IPv6-only
network would be required. However today's IPv6-only networks are
not fully capable of supporting MPLS. There is ongoing work in the
MPLS Working Group, described in [I-D.ietf-mpls-ipv6-only-gap]
to identify gaps that must be addressed in order to allow MPLS-
related protocols and applications to be used with IPv6-only
networks. This is an another example of scenario where an IPv6-only
solution could represent a valid option to solve the problem and meet
operators' requirements.
In addition it is worth to note that in today's MPLS dual-stack
networks IPv4 traffic is labeled while IPv6 traffic is usually
natively routed, not label-switched. Therefore in order to be able
to provide Traffic Engineering "like" capabilities for IPv6 traffic
additional/alternative encapsulation mechanisms would be required.
In summary there is a class of use cases that motivate an IPv6 data
plane. The authors identify some fundamental scenarios that, when
recognized in conjunction, strongly indicate an IPv6 data plane: recognized in conjunction, strongly indicate an IPv6 data plane:
1. There is a need or desire to impose source-routing semantics 1. There is a need or desire to impose source-routing semantics
within an application or at the edge of a network (for example, a within an application or at the edge of a network (for example, a
CPE or home gateway) CPE or home gateway)
2. There is a strict lack of an MPLS dataplane 2. There is a strict lack of an MPLS dataplane
3. There is a need or desire to remove routing state from any node 3. There is a need or desire to remove routing state from any node
other than the source, such that the source is the only node that other than the source, such that the source is the only node that
skipping to change at page 5, line 48 skipping to change at page 6, line 26
Access networks deliver a variety of types of traffic from the Access networks deliver a variety of types of traffic from the
service provider's network to the home environment and from the home service provider's network to the home environment and from the home
towards the service provider's network. towards the service provider's network.
For bandwidth management or related purposes, the service provider For bandwidth management or related purposes, the service provider
may want to associate certain types of traffic to specific physical may want to associate certain types of traffic to specific physical
or logical downstream capacity pipes. or logical downstream capacity pipes.
This mapping is not the same thing as classification and scheduling. This mapping is not the same thing as classification and scheduling.
In the Cable access network, each of these pipes are represented at In the Cable access network, each of these pipes are represented at
the DOCCIS layer as different service flows, which are better the DOCSIS layer as different service flows, which are better
identified as differing data links. As such, creating this identified as differing data links. As such, creating this
separation allows an operator to differentiate between different separation allows an operator to differentiate between different
types of content and perform a variety of differing functions on types of content and perform a variety of differing functions on
these pipes, such as egress vectoring, byte capping, regulatory these pipes, such as egress vectoring, byte capping, regulatory
compliance functions, and billing. compliance functions, and billing.
In a cable operator's environment, these downstream pipes could be a In a cable operator's environment, these downstream pipes could be a
specific QAM, a DOCSIS service flow or a service group. specific QAM, a DOCSIS service flow or a service group.
Similarly, the operator may want to map traffic from the home sent Similarly, the operator may want to map traffic from the home sent
skipping to change at page 8, line 42 skipping to change at page 9, line 19
o The operator may want to be able to setup a specific path for o The operator may want to be able to setup a specific path for
delay sensitive applications; delay sensitive applications;
o The operator may have the need to be able to select one (or o The operator may have the need to be able to select one (or
multiple) specific exit point(s) at peering points when different multiple) specific exit point(s) at peering points when different
peering points are available; peering points are available;
o The operator may have the need to be able to setup a source based o The operator may have the need to be able to setup a source based
path for specific services in order to be able to reach some path for specific services in order to be able to reach some
servers hosted in some facilities not always reachable through the servers hosted in some facilities not always reachable through the
optimal path. optimal path;
o The operator may have the need to be able to provision guaranteed
disjoint paths (so-called dual-plane network) for diversity
purposes
All these scenarios would require a form of traffic engineering All these scenarios would require a form of traffic engineering
capabilities in IP core networks not running MPLS and not willing to capabilities in IP core networks not running MPLS and not willing to
run it. run it.
IPv4 protocol does not provide such functionalities today and it is IPv4 protocol does not provide such functionalities today and it is
not the intent of this document to address the IPv4 scenario, both not the intent of this document to address the IPv4 scenario, both
because this may create a lot of backward compatibility issues with because this may create a lot of backward compatibility issues with
currently deployed networks and for the security issues that may currently deployed networks and for the security issues that may
raise. raise.
The described use cases could be addressed with the SPRING The described use cases could be addressed with the SPRING
architecture by having the Edge nodes of network to impose a Segment architecture by having the Edge nodes of network to impose a Segment
List on specific traffic flows, based on certain classification List on specific traffic flows, based on certain classification
criteria that would include source IPv6 address. criteria that would include source IPv6 address.
3. Acknowledgements 3. Acknowledgements
The authors would like to thank Brian Field, Robert Raszuk, John G. The authors would like to thank Brian Field, Robert Raszuk, Wes
Scudder and Yakov Rekhter for their valuable comments and inputs to George, John G. Scudder and Yakov Rekhter for their valuable
this document. comments and inputs to this document.
4. IANA Considerations 4. IANA Considerations
This document does not require any action from IANA. This document does not require any action from IANA.
5. Security Considerations 5. Security Considerations
There are a number of security concerns with source routing at the IP There are a number of security concerns with source routing at the IP
layer [RFC5095]. The new IPv6-based routing header will be defined layer [RFC5095]. The new IPv6-based routing header will be defined
in way that blind attacks are never possible, i.e., attackers will be in way that blind attacks are never possible, i.e., attackers will be
skipping to change at page 9, line 41 skipping to change at page 10, line 24
mechanisms, such as packet filtering, cryptographic security, etc. mechanisms, such as packet filtering, cryptographic security, etc.
6. Informative References 6. Informative References
[I-D.bhandari-dhc-class-based-prefix] [I-D.bhandari-dhc-class-based-prefix]
Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Systems, C., Halwasia, G., Gundavelli, S., Deng, H.,
Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
based prefix", draft-bhandari-dhc-class-based-prefix-05 based prefix", draft-bhandari-dhc-class-based-prefix-05
(work in progress), July 2013. (work in progress), July 2013.
[I-D.filsfils-rtgwg-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-rtgwg-
segment-routing-01 (work in progress), October 2013.
[I-D.filsfils-rtgwg-segment-routing-use-cases] [I-D.filsfils-rtgwg-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B., Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg- Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg-
segment-routing-use-cases-02 (work in progress), October segment-routing-use-cases-02 (work in progress), October
2013. 2013.
[I-D.filsfils-rtgwg-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-rtgwg-
segment-routing-01 (work in progress), October 2013.
[I-D.filsfils-spring-segment-routing-mpls] [I-D.filsfils-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing with MPLS data plane", draft-filsfils- "Segment Routing with MPLS data plane", draft-filsfils-
spring-segment-routing-mpls-01 (work in progress), April spring-segment-routing-mpls-02 (work in progress), June
2014. 2014.
[I-D.ietf-mpls-ipv6-only-gap]
George, W. and C. Pignataro, "Gap Analysis for Operating
IPv6-only MPLS Networks", draft-ietf-mpls-ipv6-only-gap-00
(work in progress), April 2014.
[I-D.ietf-mpls-seamless-mpls] [I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft- M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-06 (work in progress), February ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
2014.
[I-D.ietf-sfc-problem-statement] [I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-05 Problem Statement", draft-ietf-sfc-problem-statement-07
(work in progress), April 2014. (work in progress), June 2014.
[I-D.kumar-sfc-dc-use-cases] [I-D.kumar-sfc-dc-use-cases]
Surendra, S., Obediente, C., Tufail, M., Majee, S., and C. Surendra, S., Obediente, C., Tufail, M., Majee, S., and C.
Captari, "Service Function Chaining Use Cases In Data Captari, "Service Function Chaining Use Cases In Data
Centers", draft-kumar-sfc-dc-use-cases-02 (work in Centers", draft-kumar-sfc-dc-use-cases-02 (work in
progress), May 2014. progress), May 2014.
[I-D.lepape-6man-prefix-metadata] [I-D.lepape-6man-prefix-metadata]
Pape, M., Systems, C., and I. Farrer, "IPv6 Prefix Meta- Pape, M., Systems, C., and I. Farrer, "IPv6 Prefix Meta-
data and Usage", draft-lepape-6man-prefix-metadata-00 data and Usage", draft-lepape-6man-prefix-metadata-00
(work in progress), July 2013. (work in progress), July 2013.
[I-D.previdi-6man-segment-routing-header] [I-D.previdi-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6
Segment Routing Header (SRH)", draft-previdi-6man-segment- Segment Routing Header (SRH)", draft-previdi-6man-segment-
routing-header-00 (work in progress), March 2014. routing-header-01 (work in progress), June 2014.
[I-D.quinn-sfc-nsh] [I-D.quinn-sfc-nsh]
Quinn, P., Guichard, J., Fernando, R., Surendra, S., Quinn, P., Guichard, J., Fernando, R., Surendra, S.,
Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A., Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A.,
Elzur, U., McConnell, B., and C. Wright, "Network Service Elzur, U., McConnell, B., and C. Wright, "Network Service
Header", draft-quinn-sfc-nsh-02 (work in progress), Header", draft-quinn-sfc-nsh-02 (work in progress),
February 2014. February 2014.
[I-D.troan-homenet-sadr] [I-D.troan-homenet-sadr]
Troan, O. and L. Colitti, "IPv6 Multihoming with Source Troan, O. and L. Colitti, "IPv6 Multihoming with Source
 End of changes. 18 change blocks. 
30 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/