Internet DRAFT - draft-vandevelde-spring-flow-aware-v6transport
draft-vandevelde-spring-flow-aware-v6transport
SPRING Working Group G. Van de Velde, Ed.
Internet-Draft Nokia
Intended status: Standards Track G. Fioccola, Ed.
Expires: September 10, 2017 Telecom Italia
P. Muley
Nokia
March 9, 2017
Flow Aware IPv6 Segment Routing
draft-vandevelde-spring-flow-aware-v6transport-00
Abstract
Flow-Aware transport of Pseudowires over an MPLS Packet Switched
Network (RFC6391) introduces an ECMP use-case, making assumption that
the payload of a pseudowire comprises of a number of distinct flows.
RFC6391 provides a mechanism for fine flow granularity beyond the
individual pseudowire, helping better flow granularity for ECMP
purpose. To identify the granular pseudowire flows the concept of
MPLS Flow Label is introduced. Furthermore RFC6391 defines the
required LDP protocol extensions to exchange the MPLS Flow Label
between LDP speakers.
Another method to exchange MPLS flow labels is found in draft-ietf-
bess-fat-pw-bgp. Draft-ietf-bess-fat-pw-bgp defines extensions
required to synchronise flow label state between PEs using BGP-based
signalling procedures. This draft assumes MPLS is the transport
technology used.
This draft extends the applicability of draft-ietf-bess-fat-pw-bgp
and uses the BGP derived flow label for IPv6 Segment Routing
transport. The PE responsible for imposing the IPv6 Segment Routing
top level header will in addition to an IPv6 header AND the IPv6
Source Routing header ALSO impose the BGP derived Flow Label as the
IPv6 outer header flow Label. This functionality will provide fine
ECMP granularity of IPv6 Segment routing enabled pseudowire transport
services.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Van de Velde, et al. Expires September 10, 2017 [Page 1]
Internet-Draft Flow Aware IPv6 Segment Routing March 2017
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation and Use Case . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
Van de Velde, et al. Expires September 10, 2017 [Page 2]
Internet-Draft Flow Aware IPv6 Segment Routing March 2017
1. Introduction
The IPv6 Header Format defined in RFC2460 introduces the availability
of an 20-bit flow label in the base IPv6 Header.
The draft draft-ietf-bess-fat-pw-bgp defines the exchange of a flow
label (RFC6391) between two BGP speakers. The application realm in
draft-ietf-bess-fat-pw-bgp is MPLS and the embodiment of the
exchanged flow label is an additional MPLS Label Stack Entry (LSE)
imposed at the Bottom of Stack.
The original flow-Aware Transport of pseudowires flow label defined
in RFC6391 assumes an MPLS enabled dataplane and did not consider an
IPv6 Segment Routing Dataplane. The 20-bit label value exchanged
through BGP according draft-ietf-bess-fat-pw-bgp can be used by a PE
router imposing the outer IPv6 Segment Routing header upon an ingress
packet. The 20-bit Flow-Aware transport for pseudowires flow label
is copied into the outer IPv6 header 20-bit IPv6 Flow label header
field. Together with the imposed Segment Routing IPv6 Source Routing
Header (SRH) the 20-bit value will allow any router within the IPv6
segment routing domain use traditional IPv6 hashing ECMP mechanisms
with fine granularity for an IPv6 pseudowire transpoort service.
An additional benefit is that this technology allows a network
management station, having awareness of the flow-aware transport of
pseudowires flow labels AND the IPv6 Flow Label imposed upon the IPv6
SRv6 packet AND the imposed IPv6 Source Routing packet Header, allows
to harvest advanced network wide analytics and passive monitoring
data. Indeed the IPv6 source routing header provides exact
information about the traffic exchanged between ingress and egress
PE, and in addition the IPv6 Flow Label provides the granular
awareness of the flows within this aggregate flow.
2. Operation
Assume the following simple network topology:
Source---PE1----SRv6 Network----PE2---Destination
Source sends a packet to Destination. The packet on its journey
towards Destination is received by PE1. PE1 adds relevant IPv6
segment Routing headers to reach Destination by (1) steering the
packet through the network towards the egress PE2, and (2) on PE2
hand-off the packet into the appropriate (VPLS) service context. In
addition, the Flow Aware IPv6 Segment Routing flow label is copied to
the transport IPv6 Segment Routing transport header to provide ECMP
entropy on more granular level as a single pseudowaire transport
tunnel.
Van de Velde, et al. Expires September 10, 2017 [Page 3]
Internet-Draft Flow Aware IPv6 Segment Routing March 2017
Routers within the IPv6 Segment Routing network steer the packets
from ingress PE1 to egress PE2 as instructed by the imposed SRv6
Source Routing Header. However, when a router has multiple equal
cost paths available, then ECMP can be used to loadbalance the flows.
The information within the IPv6 Segment Routing header including the
20-bit flow label field is used for load-balancing purpose. This
technology allows load-balancing with fine granular flow
identification within a single pseudowire.
3. Motivation and Use Case
[5] discusses the desired capabilities for MPLS flow identification
to implement in-band performance monitoring of user data packets. A
method of loss and delay measurement in MPLS networks was defined in
RFC6374. But, when used to measure packet loss, RFC6374 depends on
the use of the injected OAM packets to designate the beginning and
the end of the packet batch over which the measure is done. As
described in [6], this method does not work properly in case of
packet misordering and the problem can be defeated by the method
proposed in [4].
In general, modern networks, if not oversubscribed, normally drop
very few packets, thus packet loss measurement is highly sensitive to
counter errors. Also, on the other side, it may be useless to assess
active performance measurement methods with synthetic traffic. At
the same time network operators need to be able to measure the loss,
the delay and the delay variation of the actual data traffic by using
passive performance measurement methods, because of more demanding
service level requirements.
Without some form of marking, such as that proposed in [4], it may
not be possible to achieve the required accuracy in performance
measurement of data traffic. One of the most efficient and
straightforward method is the Alternate Marking described in [4].
The solution here proposed extends this passive performance
measurement technique in the context of IPv6 Segment Routing network
and the application is based on the Ipv6 Flow Label Marking.
4. Security Considerations
tbc
5. Acknowledgements
tbc
Van de Velde, et al. Expires September 10, 2017 [Page 4]
Internet-Draft Flow Aware IPv6 Segment Routing March 2017
6. IANA Considerations
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
[2] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
Regan, J., and S. Amante, "Flow-Aware Transport of
Pseudowires over an MPLS Packet Switched Network",
RFC 6391, DOI 10.17487/RFC6391, November 2011,
<http://www.rfc-editor.org/info/rfc6391>.
[3] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>.
[4] Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L.,
Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate Marking method for passive performance
monitoring", draft-ietf-ippm-alt-mark-04 (work in
progress), March 2017.
[5] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G.
Mirsky, "MPLS Flow Identification Considerations", draft-
ietf-mpls-flow-ident-04 (work in progress), February 2017.
[6] Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow
Labels", October 2016.
Authors' Addresses
Gunter Van de Velde (editor)
Nokia
Antwerp
BE
Email: gunter.van_de_velde@nokia.com
Van de Velde, et al. Expires September 10, 2017 [Page 5]
Internet-Draft Flow Aware IPv6 Segment Routing March 2017
Giuseppe Fioccola (editor)
Telecom Italia
Torino
Italy
Email: giuseppe.fioccola@telecomitalia.it
Praveen Muley
Nokia
805 E. Middle field road
Mountain View, California 94043
USA
Email: praveen.muley@nokia.com
Van de Velde, et al. Expires September 10, 2017 [Page 6]
